Имею в виду не какие могут быть идеи (шучу :) их я выслушаю с еще большим удовольствием), а как сделать то, что пилишь для Голос, частью Голоса.
При реализации интерфейса для Escrow я столкнулся с тем, что в нодах Голос крайне ограниченное API для Escrow. Нет возможности получить список всех своих Escrow (о чужих уж и речь не идет), и приходится помнить их номера.
Это можно как-то исправить, с учетом того, что я программирую на C++ и Go? :) Или только решить проблему по принципу Offchain DB (это когда dapp сам хранит в своей БД нужную информацию)? Что ж, в этом тоже есть что-то...
Но с таким же успехом я могу сделать форк Golos, в котором это будет в API ноды, и поднять свою ноду. При условии, разумеется, совместимости, чтобы она работала в той же цепочке.
Возможно, Escrow не самый удачный пример, потому что не востребованы (этого я не знаю, мои сервисы не следят и не будут следить за вами :) поэтому нет статистики) И поэтому встраивать его непосредственно в wallet.golos.id вряд ли стоит. Да к тому же это сложно из-за самобытности (он на Vue и TS, а wallet.golos.id на React и JS). Но скажем можно было бы сюда добавить ссылку...
Ну и, дальше - больше. В комментариях под постом про интерфейс Escrow я узнал, что есть люди, которые хотят пулы ликвидности. Но, насколько я понял, для их реализации нужны смарт-контракты, а их в Golos нет... Альтернатива смарт-контрактов - это обычно внести изменения прямо в саму ноду в рамках очередного ХФ... А такие вопросы вообще решаются? :)
@bobik7, Вот если бы Аген между Escrow выступал не человек, которому нужно доверять а автоматизация (код) то это можно будет предлагать людям которые спекулируют P2P | OTC
@docsait, Кристине и шлюзов хватает ;)
@ecurrex-ru, да бывают ситуации, что нужно обменять монеты друг другу без давления на стакан - к примеру это перевод таких сумм или активов
которых просто в стакане нет, жаль что Escrow не универсален
@bobik7,
По-моему, просто напрашивается идея плагинов к ноде, которые можно подключить для своих целей, не меняя основной код. Я в детали не вникал, но какая-то модульность уже, кажется, имеется.
@shuler, Есть там плагины, только они на С++ и используют базу данных ноды. Сложна очень. Проще написать свой "плагин", который перебирает блоки и складывает данные в свою базу данных. Проще чем ждать милостей от природы и удобнее, можно как хочешь данные складывать и показывать. Затратнее конечно, нужно где то базу данных размещать, чем просто статично где то свой сайт залить.
Но и в ноду добавлять новые фичи еще более затратнее. В человекочасах и деньгах. Вот и вопрос, стоит ли оно того?
Можно блоки перебирать get_blocks, а можно метод event_plugin/
get_events_in_block дергать, который помимо операций, еще и эвенты аки виртуальные операции выдает. Я так и делаю в своих программках.
@bitwheeze, я не возражаю, чтоб плагин делал свою БД или что угодно, я просто сомневаюсь, что править код ноды — это хорошая идея, с поддержкой при обновлениях будет геморрой, поэтому как альтернативу делания своей ноды с модифицированным API и предлагаю вынести весь нужный функционал в плагин. С архитектурной точки зрения это правильней, хотя насколько там "сложна" в деталях, я не в курсе.
@shuler, ну вот они, плагины и имеются уже в ноде. Есть консенсусная часть. К примеру переводы монет, голосование, посты. Они должны быть одинаковыми везде. А есть неконсенсусная часть. К примеру топ постов по числу комментариев. Такие вещи, неконсенсусные выполнены в виде опциональных плагинов. Плагины так же реагируют на операции, эвенты и складывают данные в свою табличку в базе данных ноды.
То, что не хватает @bobik7, как раз из того разряда. Это можно реализовать плагином не трогая ноду, но как я выше написал, там сложно очень. По крайней мере лично для меня. Может @bobik7 или вам это легко сделать. Добавить плагин escrow, который будет хранить список контрактов, пользователей и давать возможность подгружать списко по акканту или по escrow.
Либо все делать у себя, писать свой скрипт и использовать свою базу данных.
@bobik7, скорее всего так. те. вот есть две "фичи" на голосе - шлюзы и пасьянс (которые я знаю, мб. еще что-то есть, но для примера хватит и их). вроде как все это "голос", но вся нужная инфа для их функционирования хранится в локальных базах у "операторов".
так что если придумал что-то этакое - пили отдельным сервисом, которым ты и будешь рулить самостоятельно. а из голоса будет просто выход в него. так и никого ничего просить не надо (самое главное) и можешь менять хоть по 10 раз на дню "свой собственный код", главное чтобы из голоса выглядело прилично. "и все чинно, благородно, по-старому" (с).
@bobik7, в остальном, любые вопросы решаются, почти всегда обсуждением
Прямой путь, да, строить "свой квартальчик в городе блокчейна", особо не теряя время на вышеописанное, радуя новостями где что появилось и изменилось
и получая вознаграждения в виде донатов, заявок в фонд на компенсацию от сообщества за улучшения + запуск своего делегата/ов c последующей поддержкой от сообщества... Ведь ты уже приносишь пользу.
@bobik7, Escrow увы действительно не самый удачный пример
просто потому что в текущем виде он мало кому интересен тут
как часто бывает, "функционал аля на пригодится"
хотя понятно что и его можно обыграть кейсами после доработок, обогатив UIA и т.д.
Вопрос "зачем" и "для кого", расширенного ответа за годы я не видел.
@bobik7, по опыту сервисы строятся чаще во вне, когда ДАПки как ты и отметил, запускаются на своей БД расширяя и обогащая "бедный опционал" БЧ,
банально по причине удешевления изменений на порядки чем работа в плюсах + тесты + риски багов и падения БЧ в целом
а значит недели споров и обсуждений на предмет "зачем пихать в ноду то или иное", "для кого" и "с какой целью"
если же в АПИ нужны популярные правки, можно доработать и там
но, нужна поддержка масс + тех кто сделает/оплатит/потестит, прежде чем это обновят на всех нодах
либо править на своей АПИ-ноде для своего сервиса, не залезая в консенсусную часть кода (форк это другое, когда консенсус порушил и цепочка иная со своими нодами и т.д.)
в этих случаях, тогда и спрашивать некого, твоя нода + твой сервис