Мысли вслух по поводу распределённой социальной системы

Забавно, что пару лет назад, когда меня интересовал промежуточный слой XML для хранения логики BB-code разметки перед конвертацией в HTML (linux.org.ru) никто не предложил DocBook XML. Похоже, это то, что нужно. И позволит унифицировано задействовать разметки в других форматах, хоть Markdown, хоть AsciiDoc. Надо будет попробовать задействовать на практике на форуме. Лишняя сущность, но упростит обработку и расширение.

А в свете сабжа — есть такая проблема. Хочется, чтобы ноды могли использовать документы в разной исходной разметке. Кому-то нравится Markdown, кому-то — Creole. Где-то, как у нас, всё делается на BBCode. Соответственно нужно было выбирать:
— либо все ноды должны поддерживать все стандартные форматы
— либо нестандартные для данной ноды документы показываются как есть, исходниками
— либо обмениваться готовым HTML, намертво прибиваясь к разметке

Теперь, вроде, есть неплохая альтернатива. К исходнику можно просто прикладывать DocBook XML.

Переход к практической части.

Так и не подобрал адекватной системы прямого обмена данными в каталогах. Вот старая версия BTSync была бы неплоха. Но её убили. Syncthing требует ручного связывания обменников. IPFS не расшаривает каталоги. И т.п.

Поскольку, по большому счёту, я изначально задумывал не привязываться к транспорту, лишь бы был обмен данными, решил пока базироваться на первоначальной идеи использовать Git. Только чтобы не мусорить аттачами на GitHub, поднял Gogs у себя на HBR. И засинкаю ещё на HTZ позже.

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

Т.е. обмен данными будет работать по принципу:
1. Написали сообщение на форум
2. Система коммитит сообщение в репозиторий
3. Репозиторий дёргает за хуки всех, кто тянет с него данные (или это делается при периодических опросах, если самостоятельное подключение)
4. Дёрнутые ноды скачивают изменение и регистрируют изменённые документы у себя

...

Попробую теперь прикрутить экспорт данных (пункт 2) к практическому репозиторию. Простой коммит сделать совсем несложно. Сложнее делать это с учётом аттачей и редактирования.

В копилку:

Сделал ряд упрощений, благодаря которым уже начинаю отрабатывать взаимодействие узлов. Даже не столько упрощений, сколько отвязок от конкретных решений в одних местах и привязок в других. Для начала — отказался от идеи большого централизованного git-репозитория. Идеология разбивки на репозитории по объёму очень усложняла задачу.

Сейчас есть просто поток постингов (вообще — любых объектов, но отрабатываю на форумах) в YAML-Markdown формате, которые могут получать все желающие подписчики по любому доступному транспорту. Я, например, сейчас тупо раздаю их по BTSync. Думаю задействовать также MQTT. Но, вообще, протокол обмена может быть абсолютно любой — rsync, blockchain и т.п.

На одной ноде пишется пост на форуме, он передаётся нодам-приёмникам, тем парсят и заталкивают в свои форумы.

— Обмен пока осуществляется только для публичных открытых сообщений. Предполагается, что будет два уровня доступа. Полностью открытый и с «небезопасным контентом» (целевая нода будет сама решать, давать доступ к этим данным или нет). Приватные данные или вообще не будут отдаваться в обмен, или будут отдаваться по отдельным каналам.

— Каждый пользователь, кроме ссылки на профиль ноды, подписывается по md5 от e-mail. Это скрывает e-mail от публичной раздачи, позволяет связывать пользователей, пишущих на разных нодах и выдавать общий аватар через Gravatar на прочих нодах.

— Есть идея сделать UUID файла сообщения по формуле f2fs-хеша. Что позволит вытаскивать сообщения через f2fs с любой ноды, не обязательно привязанной прямо. Плюс автоматически избегаем дублирования сообщений при перекрёстных обменах.

— Пока есть проблема с аналогичным решением для топиков. Можно, конечно, просто пользоваться одним UUID, выданным нодой-стартером, но будут проблемы при модификациях постингов, переносах сообщений и т.п. Тут надо подумать уже на практике. Пока переданные данные ещё не парсятся и никуда не загружаются.

— Файловый обмен (аттачи и т.п.) идёт (будет идти) по f2fs.

— Если при получении постинга по обмену не находится уже имеющийся ранее топик с указанным UUID, то с ноды источника тянется весь указанный топик и создаётся на приёмной машине. Таким образом получается автоматическая консистентность актуальных данных на всех машинах-приёмниках. Старые, «архивные» топики таким образом на новых машинах не распространяются, что позволяет не перегружать слабые системы, не заинтересованные в хранении архивов. Одновременно таким способом повышается вес и полезность старых систем.

— Аналогично обстоит дело с форумами, пользователями. Но с последними нужно дорабатывать систему регистрации юзеров на конкретных движках — если при регистрации хеш указанного e-mail уже есть у какого-то удалённого юзера, то новый регистрант оформляется в этот аккаунт.

— Конкретные топики, форумы или авторы могут на приёмной ноде блокироваться.

— Думаю для начала делать привязки для движков MyBB (как самый для меня полноценный) и FluxBB (интересен тем, что разработка базируется на composer-зависимостях).

— Вначале планирую открыть пару тестовых «альтернативных» форумов Авиабазы (со своими правилами), отработать двухстороннее взаимодействие с ними и односторонний приём информации с конференции АвиаПорт.Ru и попробовать добывать данные для одностороннего же постинга парсингом других форумов, например, linux.org.ru

— В качестве контента передаваться будет исходный код, введённый пользователем, без разметки. Возможно (не уверен в правильности и нужности) также передаваться будет и HTML, транслированный сервером. Возможно, отдельным вполне автономным файлом в f2fs.

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

Сценарий примерно такой.

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

Аналогично может решаться вопрос с форумами и юзерами.

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

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

• UUID объекта (формат не утверждён, сейчас — произвольная строка latin1 до 64 символов)

Нужно подумать также о хешах объектов в p2p-ФС. Пока в разработке участвует только ipfs, соответственно, поле с хешем можно добавить в те же таблицы. Но если для надёжности будет использоваться несколько ФС?

FluxBB не понравился из-за нерасширяемости. Т.е. гнать тупо текст — можно и сейчас (что и делается на тестовом). А вот что-то серьёзнее, хотя бы разметку нормальную организовать и граватары включить — нужно жёстко патчить ручками. А окончательно меня от него оттолкнуло отсутствие аттачей. Как их трансляцию туда делать? В общем тот же PunBB...

...

С другой стороны — всё равно обмен аттачами думаю делать через ipfs, так что передачу их в fluxbb не вопрос организовать на этапе импорта им сообщений. Так что, наверное, допилю движок импорта. Сам, правда, пользоваться не буду

...

Вот для phpBB, при всей моей к нему ненависти (внутренняя структура данных ужасная), наверное, адаптер придётся писать. Один из присоединяемых к системе сторонних форумов — на этом движке.

Ещё нужны будут адаптеры под LiveStreet и Wordpress. Это для категорий статей.

Ну и попробую организовать R/O трансляторы с LOR и Opennet

Обширная информация к размышлению:

Идеи «векторного гипертекстового фидонета» прямо таки витают в воздухе

Интересный побочный эффект от такой системы.

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

Теперь можно будет пробовать тупо прилепить адаптер импорта данных распределённой системы и получить «живую» систему. Сразу будет видно, насколько она удобна, насколько качественная архитектура. И можно в таком автоматически пополняемом виде оставить, периодически щупая на тему удобства использования с практическими данными (которые будут экспортироваться обратно в распределённую систему).

Наверное, для старта попробую Anahita:


Пока поднял без импорта распределённых данных, позже попробую написать адаптер.

Также нужно будет рассмотреть:

• Elgg - Open Source Social Networking Engine. — соц. сеть
• Flarum – Forums Made Simple — форум
• FluxBB - fast, light, user-friendly PHP forum software — форум, но этот итак в работе (простейший импорт есть)
• https://gnu.io/social/ — соц. сеть
• Oxwall ® - PHP Social Networking Software | Community Script — соц. сеть
• phpBB • Free and Open Source Forum Software — форум. Ненавижу его, но можно попробовать. Ибо очень популярен.
• Community Forum Software - Vanilla Forums — форум

Вот с чем пока концептуальные проблемы обмена — это с CMS/Wiki. Как правило, там активно используется большое число внутренних ссылок, часто привязанных к архитектуре приложения. Надо решать вопросы с их конверсией.

...

Кстати, другая проблема — внешние ссылки вообще. Если ведётся разработка «неуничтожимой» (с долго, по крайней мере, хранящимися данными), важно сохранять и страницы, на которые мы публикуем ссылки. Иначе через 5 лет от них в доступе остаётся половина, через 10 лет — единицы. Надо утягивать и сохранять страницы целиком. И тут — проблема. Прижившихся однофайловых форматов, которые можно загружать куда-то в p2p-хранилища и потом открывать в браузере — нет. Хранить архивы можно, но мало смысла — их нельзя открыть в браузере. Разбирать страницы и выкладывать контент в p2p-хранилище по частям с заменой вызовов на p2p? — работоспособное решение, но только отчасти (например, в ipfs нельзя выложить CSS и показать его как работоспособный CSS). И громоздкое очень.

В копилку, надо будет оценить:

Можно будет гостей отправлять на гейт с этим движком. Хотя не так удобно, как если бы сразу при ответе аутентифицироваться, но лучше, чем ничего. И список сетей солидный.