Список документов по проекту

Предварительный todo список с приоритетами

Важные вопросы

Выбор языка/платформы для разработки проекта
Выбор языка/платформы для плагинов
Расстановка приоритетов

Общая концепция

Интерфейсы взаимодействия

Графический интерфейс
RPC запросы по http с json-сериализацией (на основе проекта bitcoin а так же к функционалу плагинов)
Доступ к функционалу из встроенного языка (см. плагины ниже)
multichain - доступ к нестандартным blockchain (другие сети, например namecoin, litecoin)

Модульная система (плагины)

Объектно-ориентированный доступ к интерфейсам
Язык разработки кода плагинов - javascript
Язык разработки GUI - html (из gui не должно быть прямого доступа к внешним http запросам, если это не разрешено)

Выбор javascript и html обусловлен очень высокой популярностью и очень низким порогом вхождения.

Репозитарий для плагинов

Как только зависимых приложений у проекта становится больше нескольких десятков, пользоваться этим становится очень сложно (это очень важно для популяризации проекта), необходимы механизмы для автоматизации основных действий над этими приложениями как для пользователей так и для разработчиков.

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

Система подписи плагинов

у плагинов могут быть авторы, его опубликовавшие в репозитарии
плагины подписываются (хотя бы средствами кошелька bitcoin)
запуск/установка только подписанного плагина (исключение - плагины в режиме отладки)
авто-обновление плагинов (только если у них не изменилась структура разграничения прав, плюс по требованию разработчиков)

Система зависимостей плагинов (не превратить в сложную и непонятную большинству систему, а то создавать еще одну систему портежей с use флагами как gentoo - перебор)
Децентрализованный репозитарий

своя распределенная mesh-сеть (кстати можно попытаться протащить изменения в стандарт bitcoin, чтобы использовать ее сеть для распространения информации - в сети нужна возможность рассылки коротких шифрованных сообщений между клиентами, не хранение)
своя распределенная база данных, основанная на DHT или любой другой технологии (есть примеры freenet, i2p тоже что то пытаются разработать, сначала можно тупо хранить все у всех) - это просто key->value БД и публичные списки

защита от флуда - статистикой и рейтингами, например плагин будет виден по умолчанию если

сортировка по рейтингу (плюс черные и белые списки пользователей)
статистика установок
комментарии
он новый (небольшой срок по таймауту)

100% защититься невозможно, любой децентрализованный проект может быть задушен флудом, но если будет серьезное развитие можно пробиться в blockchain bitcoin и как-нибудь воспользоваться его мощью для защиты (надо думать)

подписи и шифрование с ключами-адресами bitcoin, нет необходимости городить что то новое

Социальная состовляющая и организация репозитария

Категории плагинов

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

Пользователи, комментарии, лайки, статистика

Система разграничения прав доступа плагинов к данным и другим возможностям:

кошелек (фактически все что сейчас позволяет стандартный клиент bitcoin, баланс, транзакции)
доступ к blockchain (чтение - поиск в блоках и анализ транзакций, запись - формирование своих транзакций)

работа с языком построения транзакций (разбор до лексем, формирование из лексем в языке прямо из javascript) - формирование может быть медленным из интерпретируемого языка, можно оформить в виде компиляции в нативный код (например компилировать в бинарный код при установке плагина), но важно продумать ограничения.
поиск транзакций по шаблону (клиент bitcoin сейчас так и делает, выявляет 4 стандартных сценария транзакций), разработать язык, возможно хватит обычного regexp

создание или расширение элементов GUI
http/rpc запросы ‘наружу’, отдельно разрешается доступ по ‘белому списку’, либо доступ всюду кроме ‘черного списка’ (собирается минимальная статистика)
доступ к функционалу плагина из вне с помощью штатного rpc клиента
доступ к функциям других плагинов

отдельно указывается доступные уровни прав доступа и квоты

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

readonly: доступ к методам ‘только чтение’ - это только получение информации, методы не изменяют никакого состояния - например текущий баланс кошелька
write: доступ к методам на ‘изменение состояния и данных’ - например создание транзакции это изменение
root: привилегированный доступ (....)

Система квот на ресурсы, в т.ч. к ресурсам, предоставляемых плагинами

как минимум это доступ к нагрузке процессора
размеры в хранилищах (плагин не может создать данных в другом плагине, например БД, больше чем указано в квотах, за этим следит этот второй плагин, нужен только инструментарий)
количество и частота запросов во времени

Предложения по плагинам

Торговые плагины

унифицированный интерфейс (gui, классы, rpc)
доступ к торговым площадкам (mtgox/btc-e/...) - совершать торговые операции, ввод и вывод (например работа с mtgox code)
доступ к электронным кошелькам (liberty reserve, paxum, okpay, likpay,... webmoney,yandex, qiwi,...) - позволит совершать торговые операции напрямую между клиентами (может потребовать посредников или иные сервисы обеспечения транзакций и гарантий)

Процессинговая система

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

Майнинг

доступ к пулам майнинга (пример реализации - solidcoin)
p2pool

Работа с иными blockchain (namecoin, litecoin, ..)
Поддержка escrow
Альтернативные виды транзакций bitcoin
Альтернативные GUI