TL;DR, вот проект: https://invoice.build
ссылки на все остальное, что есть в открытом доступе, указаны в конце этого поста.

Я открываю исходный код, дорожную карту, аналитику, *все.

Для тех из вас, кто чувствует себя комфортно в мире открытого исходного кода, это, вероятно, не кажется чем-то большим, но для меня это так. Я разработчик-самоучка, поэтому у меня затяжной синдром самозванца и неуверенность в себе по поводу кода, который я пишу. Я занимаюсь онлайн-проектами не менее 6 лет, и это никуда не делось.

Я также склонен держать свои проекты в секрете, пока у меня не появится что-то разумно отшлифованное, чтобы поделиться им. Так что выставлять все напоказ — это просто немного страшно… Но что самое худшее, что может случиться?

  1. Я мог бы быть полностью осмеян за качество кода!

2. Живой проект может быть взломан в результате случайного раскрытия некоторых секретов среды или уязвимости фреймворка/зависимости.

3. Кто-то копирует все приложение и делает его более успешным.

4. Никому нет дела и все это бессмысленно.

Ого, это то, что есть.

Если кто-то копирует полностью, то это, по крайней мере, своего рода проверка идеи, и первые два случая в долгосрочной перспективе приведут к лучшему коду. Так что я думаю, учитывая все обстоятельства, потенциальная выгода от того, что просто больше не будет строиться в частном порядке, стоит рисков.

Я также делаю это в духе ETHOnline, я думаю, что это в основном для проектов и протоколов с открытым исходным кодом, и хотя я изначально не разрабатывал invoice.build как проект с открытым исходным кодом, это не Ethereum. протокол (пока), кто знает, куда он может пойти.

Задний план

Не пытаюсь кричать здесь в свой собственный рог, просто хочу дать некоторый контекст тому, почему я создаю это и почему я делаю это публично.

Изначально я был инженером-механиком в нефтегазовой отрасли, в то же время я создал массу сторонних онлайн-проектов и в итоге получил работу Full-Stack разработчика в Bitbond. Bitbond активно участвует в криптографии, мы в основном работаем с традиционными банками, предоставляющими технологии токенизации. Мы также выпустили первое в истории STO (Security Token Offering) в Германии еще в 2019 году.

В прошлом году я создал еще один побочный проект под названием Remroll, инструмент для обработки бизнес-платежей для токенов Ethereum. На данный момент Remroll обработал токены ERC20 на сумму более 100 000 долларов, в основном в виде бонусных выплат, но использование как бы выдохлось.

Однако процесс сборки Remroll привел меня к идее invoice.build. Пару раз мне нужно было выставить счет криптобизнесу, и в идеале это был бы Dai или какой-либо другой стейблкоин. Все, что мне было нужно, это симпатичная платежная страница, которая позволяла бы клиенту совершить платеж, используя кошелек по своему выбору.

У меня также был друг, который работал в одном из крупных проектов ERC20, появившихся во время бума 2017 года. Он ежемесячно выставлял счета этой компании в эфире (ETH), и этот процесс, как он описал, был мучительным.

Это в основном то, что привело меня к созданию invoice.build. Как правило, это имеет отношение к моей работе и отрасли, а особенно к некоторому опыту, который я получил в сторонних проектах.

И, наконец, идея регулярных бизнес-платежей / выставления счетов в токенах Ethereum мне интересна, поэтому я подумал, что было бы интересно построить

Идея

Краткий обзор того, что такое invoice.build и каким я хотел бы его видеть.

Идея довольно проста, invoice.build — это чисто служебное приложение, которое помогает вам создавать страницы оплаты счетов для токенов на основе Ethereum.

По крайней мере, это то, что есть прямо сейчас.

Я хотел бы предоставить API или, может быть, даже протокол Ethereum, который позволит другим приложениям легко интегрировать аналогичные функции в свои собственные приложения и DApp.

Возможно, однажды он предоставит возможность использовать более интересные платежные протоколы, которые стали возможными благодаря Ethereum, такие как Sablier, чтобы платежи по счетам можно было передавать в потоке с течением времени.

Это то, что мне так нравится в Эфириуме: компонуемость передачи стоимости, так много вариантов, и все открыто.

Почему

Так зачем все это выкладывать на всеобщее обозрение?

  1. У меня есть привычка создавать сторонние проекты в непреднамеренном скрытом режиме, и как только у меня есть MVP, я публикую его на ProductHunt, Show HN и тому подобное. У меня были небольшие успехи, но в целом это не сработало для меня. Мне нужно попробовать что-то другое, и почему бы не полную противоположность.
  2. Код очень редко является рвом.
  3. Я ничего не теряю, открывая все.
  4. Быть сверхпрозрачным ценно, это укрепляет доверие, а доверие к криптографии на данный момент является серьезной проблемой.
  5. Это дает мне возможность быть полностью прозрачным для ETHOnline.

Стек

Краткий обзор того, что я создал на данный момент, и инструментов, которые я использую:

  • Внешний интерфейс — это приложение Nuxt.js (Vue), которое подключается к MetaMask и WalletConnect для платежей.
  • Backend — это чистый Rails API, подключенный к базе данных PostgreSQL. У меня также есть приложение Express.js Node, которое действует как микросервис для API Rails для выполнения некоторых операций с данными Ethereum.
  • Размещение/развертывание выполняется на некоторых серверах Dokku, которые я запускаю в DigitalOcean.
  • База данных — это управляемая база данных PostgreSQL, предоставляемая DigitalOcean. База данных просто используется для хранения данных о счетах и ​​транзакциях, подробнее об этом в предостережении ниже.
  • Для локальной разработки я использую VScode и Docker. Вы также можете раскрутить приложение, если хотите, просто следуйте Readme здесь.

*Предостережение

Данные (база данных) не являются общедоступными. т. е. где хранятся все данные счета-фактуры. Транзакции, сделанные для оплаты счетов, очевидно, общедоступны в блокчейне Ethereum.

Долгосрочная идея состоит в том, чтобы переместить все это в цепочку. В идеале все, включая создание счетов, будет помещено в цепочку, но мне нужно найти лучший способ сделать это. Я писал смарт-контракты раньше, я даже писал комбинацию смарт-контрактов для хранения счетов в сети, но я хочу серьезно подумать об этом, смарт-контракты пугают.

В этом пространстве также есть существующие протоколы, которые я мог бы использовать, наиболее известным из которых является Request.network.

Так что база данных пока скорее временное решение. В будущем весьма вероятно, что invoice.build будет использовать только Ethereum в качестве своей «базы данных».

Я работаю над этим проектом пару месяцев в свободное время, поэтому в нем не хватает многих функций, а код явно не идеален.

Я очень открыт для обратной связи и сотрудничества (если кто-то еще думает, что это хорошая идея). Тем не менее, суть открытого исходного кода в большей степени заключается в проверке идеи о том, что сохранение конфиденциальности кода очень редко является причиной успеха или неудачи проекта, и что общедоступное создание всего ценно, даже если сам проект терпит неудачу.

Пожалуйста, найдите все соответствующие ссылки на общедоступные страницы проектов ниже.

Если вы хотите следить за тем, как я создаю invoice.build, я буду публиковать обновления, когда смогу, в Твиттере.

Ссылки

Первоначально опубликовано на garethfullers.site 12 октября 2020 г.