? Editing: Post:21.body Save Delete Cancel
Initial sync in progress...

Newest topics

Follow in NewsfeedFollowing
+ Start new topic
Loading...
stickied

Title

Body
^1 ^2 added ━ started by user_name
More topics

 

Follow in NewsfeedFollowing

Ретрансляция форумов в ZeroNet. Основные архитектурные вопросы.

Продолжаю размышлять на тему ретрансляции централизованных ресурсов в децентрализованную сеть.

~~~

Аутентификация

Как Balancer и писал, такая трансляция имеет смысл только в формате личного архива.

Причина: принципиально иной способ аутентификация пользователей и их сообщений.

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

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

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

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

Каждый пользователь имеет возможность самостоятельно организовать трансляцию и/или получать контент из других источников. В идеале, интерфейс предоставляет пользователю информацию о разных источниках одинакового контента и уведомляет о их совпадении/несовпадении.

Идентификация

Идентификация контента должна осуществляться по идентификаторам, позволяющим однозначно выполнять двухстороннее преобразование: адрес контента на сайте источнике <=> адрес в ретрансляции. Это позволит производить автоматический поиск и индексацию источников ретрансляции для контента.

У большинства платформ можно легко распарсить уникальные идентификаторы контента напрямую из html-файлов. Например:

    https://www.linux.org.ru/news/linux-general/14752961
           |~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~|~~~~~~~~|
               источник       метаданные        идентификатор

Идентификация отдельных сообщений на linux.org.ru также осуществляется с использованием легко парсибельных числовых идентификаторов.

Информационной единицей при ретрансляции является сообщение, которое идентифицируется по следующим значениям:

  • Адрес источника.
  • Уникальный идентификатор сообщения на источнике.
  • Уникальный идентификатор темы и название темы.
  • Идентификатор автора (ник).
  • Цифровая подпись ретрансляции.

Транспорт

Использование ZeroNet в качестве транспорта выглядит заманчиво, поскольку позволяет задействовать существующую развитую инфраструктуру. С другой стороны, в немодифицированном виде использование ZeroNet сталкивается с некоторыми ограничениями:

  • Обработка больших массивов данных упирается в ограничения SQLite. Для «боевого» применения приложения потребуется либо обеспечить интерфейс к полноценной СУБД (отдельным плагином к движку ZeroNet?), либо всю ZeroNet целиком патчить под использование внешней СУБД (тут под вопросом совместимость диалектов SQL и возможностей БД). В качестве тестового полигона можно использовать текущую реализацию с SQLite.
  • ZeroNet поддерживает автоматическое обновление данных в БД только из json. Использование json нарушает принцип человекочитаемости потока трансляции без специальных средств. Как минимум, необходимо проводить декодирование escape-последовательностей, чтобы добраться до человекочитаемого контента. (Опять же, эту задачу обновления БД из файлов другого формата можно решить плагином, а макет системы собрать на json.)

Формат

Есть два варианта хранения данных в файлах: группировать по автору или группировать по теме.

Первый вариант реализован в ZeroNet по умолчанию. Для работы собственных форумов ZeroNet он является единственным возможным.

Второй вариант обеспечивает человекочитаемость и возможность легкой фильтрации контента по темам. При рентрасляции неподписанных источников имеет смысл придерживаться его.

^1 ^2 geekless posted on Jan 28, 2019
Please sign innew comment
Sign in as...
Submit comment
You are running out of your allowed space, please contact the site's admin at unknown to raise your limit.
user_nameadded ^1 ^2
Reply
Body
geeklesson Jan 29, 2019 ^1 ^2
Reply

anotherneko: И ведь это будет хранить каждый пользователь. [...]

Воу. Парни, вы забываете про optional files. Плюс, хабирование, конечно же. Никто не говорит, что всё нужно засовывать в одно место. Речь идёт именно о системе как совокупности личных тематических архивов.

anothernekoon Jan 28, 2019 ^1 ^2
Reply

quirrel: Вы представляете, сколько будет весить этот объём, если гнать в ЗероНет всё без разбору?

И ведь это будет хранить каждый пользователь.

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

geeklesson Jan 28, 2019 ^1 ^2
Reply

quirrel: К слову, я помню, как Балансер вынашивал идею чисто текстового форума в ЗероНете, мне кажется, стоит подумать в этом направлении.

И я об этом. Он хотел единый механизм, что-то среднее между mail-рассылками, форумом и лентой трансляции новостей.

quirrelon Jan 28, 2019 ^1 ^2
Reply

К слову, я помню, как Балансер вынашивал идею чисто текстового форума в ЗероНете, мне кажется, стоит подумать в этом направлении.

quirrelon Jan 28, 2019 ^1 ^2
Reply

Вы представляете, сколько будет весить этот объём, если гнать в ЗероНет всё без разбору?
И ведь это будет хранить каждый пользователь.
Спам, флуд и т.п. - сколько это будет съедать?

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More