EOS или не EOS, часть 4: Изменения Голоса после форка EOS

Здравствуйте. Как я, а также некоторые другие пользователи поняли, @goloscore хотят сделать форк сети EOS, а не создавать приложение в существующем блокчейне.
О преимуществах и недостатках такого пути я уже писал, а также о том, что это лучший вариант, если ещё и маркетингом заниматься.

В этом посте хочу затронуть тему функционала форка.
Явно, что нельзя делать просто форк, дублирующий возможности ЕОСа или отличающийся несильно: мы окажемся на втором месте после EOS, причём не близ родительского блокчейна, а далеко внизу.
Этим постом хочу описать идею, которая позволит новой сети стать уникальнее.

Кратко:

Социальный блокчейн/платформа для социальных приложений.

разъяснения:

Социальный блокчейн- это значит, что там будут профили пользователей с их данными: описанием, ссылками на соцсети и сайты, контактами и т.п.
Каждый пользователь будет иметь репутацию, которая зависит от взаимоотношения с другими и честности использования сети;
У каждого пользователя есть список приложений, которыми они могут делиться с другими, ставить им апвоты или флаги. от них зависит только рейтинг приложения в популярном - выплат никаких нет.
Также можно оставлять комментарии на странице приложения.
Каждый пользователь может сообщить о создании приложения, создав его страницу. Она содержит название, описание, версии, ссылку на github, на смартконтракты, а также историю версий.
На той странице можно оставлять комментарии и просматривать их.
По сути, это те же посты, только работающие с приложениями, знающие об их обновлениях и т.п.

Для социальных приложений - значит, что основой сети должны будут стать популярные в обществе приложения/сайты: соцсети, блог платформы, развлекательные порталы, видео, аудио и фото хостинги, игры и так далее.
Должны быть созданы условия, облегчающие разработку таких приложений, причём как в API, так и на уровне создания самих DApps.

Справка:

DApps -децентрализованные приложения, работающие в сети EOS.
Часто состоят из смартконтрактов.

Способы упростить разработку социальных приложений:

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

Посты - объекты, которые могут содержать любые данные, размещаемые смартконтрактами;
Объект содержит type (Тип - именуется смартконтрактом. Пример: blogpost, forumpost, video и т.п.), заголовок, теги (Не обязательное поле), main_filde и список апвотов, если allow_votes = true в конфиге объектов данного типа;
main_filde - замена body. Здесь содержится основная часть объекта:
Для видео/аудио хостинга - файл, например, загружаемый из ipfs, для блога - текст поста, для соцсети - текст поста на стене, текст лангрид поста или что-то иное; Для интернет-магазина/маркета, где они размещаются - описание товара.
Помимо этого, есть json_metadata, куда, например, можно вставить цену (в случае коммерческого объекта), запасную ссылку на файл (Аудио/видео/фото хостинг), информацию о приложении/историю версий.

Основа сети - это смартконтракты Голоса, а также смартконтракты DApp "Каталог приложений".

Вот как раз последний и должен реализовать то, о чём я говорил в начале:

Список объектов типа app.
Пользователь может создать новый объект - добавить приложение;
Он содержит заголовок, описание (main_filde), изображение, цену, автора, разработчиков, ссылки на github и смартконтракт (Всё это в json_metadata), а также история версий, которая представляет собой ссылки на посты с версиями в аккаунте приложения, созданного в DApp, например, Голоса.

Приложение может конфигурировать тип объекта в смартконтракте:

Можно или нет проставлять апвоты (Добавляется список апвотов к объекту);
То же самое с флагами;
Прописывается, на что влияет апвот/флаг (В случае с каталогом приложений на рейтинг в популярном).

Могут быть и другие опции, но сейчас они не приходят в голову.

И составлять списки:

Популярные объекты на основе любых параметров;
Новое;
Актуальное;
И любые другие сортировки с отображением.

В Api Golos/EOS должна быть документация, примеры реализации объектов, их настроек и составления списков.

А что по экономике Голоса, по блоговой части?

Думаю, что тут ничего менять не надо будет, но кое что изменится.

Изменения:

Смартконтракты, которые можно создавать к любым транзакциям. Например, можно будет задать, что если пользователь запустил смартконтракт, который переводит средства аккаунту name, то name, согласно ему, должен поставить апвот посту аккаунта, отправившему средства. Это избавит от необходимости создания и обновления централизованных бустеров;
Можно также создать, например, смартконтракт, который, если пользователь был упомянут, производит платёж или ставит апвот.
Или контракт, вознаграждающий репостнувших пост.
Голос может превратиться в платформу для приложений, которая будет реализовывать только типы объектов постов и комментариев, а экономику будут создавать суб-приложения:
Где-то будет 10 апвотов и 2 поста в сутки без штрафа. В другом же приложении батарейка будет тратиться при публикации постов, комментариев и апвотинге, причём в зависимости от типа операции по-разному (При публикации поста - 20%, а при публикации коммента - 2%, апвот потратит 1% батарейки и так далее).
Аналог такой платформы, если говорить про компьютер - это java, устанавливаемая в Windows или Linux.