Размышления о децентрализованных сетях

Знаю про такой. Натыкался, когда изучал, что ещё работает на ActivityPub, кроме Mastodonа.

Установил acetv - довольно сносно работает много каналов, несколько пиров отдают, и я часто отдаю видно. Есть история можно проматывать.
Хотя я тв уже лет 8 не смотрю вообще и телика нет, но на всяк случай как технология. Вдруг ютуб платным станет

И ещё децентрализованный проект: PixelFed. Это распределённый аналог Instagram.

С огромным удивлением обнаружил, что все перечисленные проекты не поддерживают режим «войти с помощью». То есть, скажем, нельзя войти на какой-нибудь сервер PixelFed и выложить фото, используя свою запись на Mastodon. И это несмотря на то, что в Mastodon, в принципе, реализован протокол OAuth, но он используется для авторизации клиентских приложений.
Причем наткнулся на обсуждение 2018 года, где автору Mastodon предлагали это сделать, но увы, так ничего и не изменилось. Зато из этого обсуждения узнал о протоколе IndieAuth, который позволяет делать кросс-сайтовую авторизацию.

Ещё неплохая подборка информации по теме: github.com/BasixKOR/awesome-activitypub.

4X_Pro написал(а):

Ещё неплохая подборка информации по теме

Про, не смотрел децентрализованный р2р проект
zeronet.io/ru
Что то я не могу разобраться где там точка входа.
Кажется там реализована регистрация и авторизация в блокчейне (то о чем мы говорили в начале этой темы), как кажется и в Bastyon.com

ПС .. И кстати хотел спросить домен 4x.pro ты себе не забрал?

Позавчера опять вернулся к мыслям о том, как создать «неубиваемые» децентрализованные контентные сайты, которые могут жить без хостинга и обычного домена. Сначала крутил в голове мысль о том, что нужно использовать такой же подход, как в yggdrasil + ALFIS: аналог IP-адресов и доменных имён на основе криптографических ключей (причём одновременно такое доменное имя будет является идентификатором пользователя при активности на чужих ресурсах, как это сделано в IndieWeb). Но реализовывать маршрутизацию не виде отдельного сетевого интерфейса (что требует root-прав), а в виде proxy-приложения, которое с одной стороны, будет подключаться к нодам и обмениваться данными, с другой — держать на localhost порты, к которым будет подключаться пользователь. Причём предполагалось использовать не обычный HTTP, а сделать новый протокол транспортного уровня, который будет чуть сложнее Gemini. По сути, основное, что туда требуется добавить — это отправлять/получать элементы обратной связи: комментарии, реакции (типа лайков или рейтингов), и подписки на аналог Server Side Events или Push. А в качестве языка разметки — использовать обычные Markdown (точнее, Frontmatter, чтобы иметь возможность указать некоторые метаданные типа желаемых цветов и шрифтов для отображения) или AsciiDoc. И самое главное — никаких языков для client-side скриптов!
UPD: Сейчас поразмыслил ещё на эту тему, и пришёл к выводу, что можно не плодить отдельный протокол, а для того же Gemini ввести соглашение о том, что комментарии и реакции хранятся по адресу, который по определённым правилам выводится из основного URI. Например /.well-known/comments/<URI> и /.well-known/reactions/. А дальше Gemini-броузер, если он поддерживает такое и пользователь указал, что хочет видеть комментарии, просто делает три запроса и собирает всё воедино: саму страницу, комментарии к ней и лайки/реакции.
А сегодня днём пришла в голову мысль: а ведь маршрутизацию и передачу данных «как в yggdrasil, но на уровне отдельного приложения» заново изобретать не надо, она уже существует — это же старые добрые Torrentы!
Тогда, по сути, всё, что нужно сделать — это резолвинг децентрализованного имени в Magnet-ссылку и реализацию протокола обратной связи, который будет отправлять комментарии, реакции и тому подобное создателю сайта, который будет решать, опубликовать их или нет (естественно, вместо живого человека эту функцию при желании можно будет переложить на скрипт) и после публикации пересобирать раздачу, а также обеспечить контроль версий для Torrentов, чтобы можно было добавить файлы в раздачу без перезагрузки всего торрента с капсулой целиком.

Схема работы

0. На начальном этапе пользователь создаёт профиль (или даже несколько, если сочтёт необходимым) — выбирает себе желаемое имя, которое будет одновременно и его именем пользователя, и «доменным именем» (чтобы отличить от обычного DNS, буду писать его дальше в кавычках), и генерирует для него пару открытый/закрытый ключ. При этом делается проверка на то, что такой пары ещё не существует (не знаю, как это сделано в ALFIS, видимо, тут какие-то blockchain-технологии работают). Причём имя существует в двух вариантах: человекочитаемое, где могут присутствовать строчные и заглавные буквы, пробелы и спецсимволы и машиночитаемое, где всё приводится к нижнему регистру, а спецсимволы удаляются. Т.е. человекочитаемое может быть --==Mad Hax0(R)==-@me, а в машинночитаемом варианте, для которого будет генерироваться ключ, оно приведётся к madhax0r@me. Для защиты от киберсквоттинга, на мой взгляд, имеет смысл сделать имена обязательно из двух частей, но, возможно, где первая — это собственно имя или название, а вторая указывает на тематику/предметную область. (Чтобы имена такой сети можно было легко отличить от обычного DNS, на мой взгляд, имеет смысл вместо точки использовать какой-то другой символ, пока наилучшим вариантом считаю @.) В отличие от обычного DNS, вторая часть может быть любой, а не выбираться из ограниченного списка, как в «большом Интернете». Существование общепринятых вторых частей будет, скорее, рекомендацией (скажем, для домашних страниц будут предпочитать @home или @me, для официальных сайтов ПО — @soft или @script и т.п., но при этом можно будет сделать любой другой вариант, например intellect@board для официальной капсулы одноимённого движка). Возможно, имеет смысл сделать какие-то дополнительные правила приведения, чтобы защититься от регистрации похожих имён (аналогично тому, как я сделал это для имён пользователей в Intellect Board).
1. Пользователь запускает proxy-приложение, которое устанавливает соединения с другими нодами для ресолвинга «доменных» имён и скачивания/раздачи torrentов по мере необходимости, а также ждёт соединение от пользовательских агентов на локальном порту
2. Пользователь запускает приложение-клиент, которое подключается к локальному proxy. Пользователь вводит URL, доменную часть которого proxy-приложение преобразует в magnet-ссылку и скачивает соответствующую капсулу либо целиком, либо с учётом настроек пользователя (качать только md/не качать файлы больше определённого размера/не качать картинки и видео/не качать реакции и комментарии/качать только подкаталоги запрошенного сайта), причём в первую очередь качается тот файл, который запросил пользователь. После скачивания сайт автоматически становится на раздачу.
3. Когда файл скачан, proxy-приложение отдаёт его клиенту, которое его отображает в соответствии с MIME-типом. Также клиент может сделать запросы к дополнительным URL (кроме упоминавшихся выше /.well-known/comments и /.well-known/reactions это могут быть, например, /.well-known/sidemenu.json и /.well-known/topmenu.json для отображения меню сайта, т.к. сейчас с этим в Gemini всё плохо, можно разве что вручную сделать на каждой странице).
4. Если пользователю нравится сайт, он в клиенте может дать команду на выкачивание его целиком, если не нравится (или не намерен сохранять его надолго) — команду на немедленное удаление его из локальных раздач. В остальных же случаях скачанные капсулы хранятся в локальном кеше до тех пор, пока занимаемое ими место не превышает заданного пользователем порога, тогда начинают удаляться самые невостребованные (в идеале востребованность должна считаться с учётом как активности локального пользователя, так и запросов на скачивание соответствующей капсулы извне). Также у пользователя будет возможность помечать отдельные капсулы как важные, которые по умолчанию удаляться не будут.
5. В метаданных либо капсулы целиком, либо отдельных страниц, указывается, разрешены ли комментарии, рейтинги или иные реакции. Если да, то пользователь может написать комментарий. Важно: показ формы для комментария делается не средствами страницы, как в HTML, а полностью реализуется средствами клиента (желательно, с возможностью автосохранения, хранения нескольких черновиков и т.п.) Далее пользователь выбирает профиль, от имени которого будет делаться отправка, клиентское приложение формирует запрос на комментарий, подписывает его соответствующим ключом и отправляет на хост создателя капсулы. Как это реализовать именно на torrentах — пока не хватает знаний, но в старых P2P-клиентах (eDonkey или Gnutella) такая возможность была. Если хост создателя недоступен, запрос ставится в очередь (аналогично тому, как это делается с письмами Email). Возможно так же существование хостов-релеев.
6. Proxy-приложение создателя капсулы проверяет цифровую подпись отправителя запроса, его наличие в чёрных списках, возможно, какие-то другие признаки спамности комментария и отправляет уведомление клиентскому приложению создания капсулы (как вариант, для управления капсулой может использоваться отдельное приложение и свой протокол). Создатель капсулы принимает решение, опубликовать комментарий или нет (либо могут быть автоматические правила принятия решения).
7. В случае публикации комментарий дописывается в файл с комментариями данной капсулы и производится пересборка раздачи. Вот тут-то и потребуется контроль версий для Torrentов. Если верить Google ИИ, сейчас просто добавить файл в раздачу нельзя, поэтому, видимо, придётся реализовывать это таким путём. «Доменное имя» создателя капсулы начинает резолвиться в новую magnet-ссылку. Пользовательские proxy-приложения для всех сохранённых капсул раз в сколько-то минут проверяют изменения «домена» (причём интервал проверки может уменьться для тех, для которых был отправлен запрос на реакцию/комментарий), и, в случае изменения, запрашивают метаданные новой капсулы. Затем сверяют хеши файлов в старой и новой, удаляют пропавшие, и докачивают недостающие, приводя сохранённую копию в актуальное состояние.
Ну а раздача своего сайта-капсулы делается предельно просто: в какой-либо каталог выкладываются markdown-файлы и вспомогательные (картинки, видео, звук и т.п.), после чего proxy-приложению указывается (либо в настройках, либо с помощью клиентского приложения), что такой-то каталог нужно проассоциировать с таким-то пользовательским ключом.
8. Аналогично пункту 5, можно предусмотреть возможность отправить сообщение владельцу сайта в произвольной форме (аналог Email) и запроса на создание новой темы (тут можно в метаданных описать необходимые поля). При этом такие сообщения могут пересылаться в зашифрованном виде.
9. Каждый пользователь может публиковать рейтинг социального доверия (причём пользователь может выбирать, отображать там всех, либо только тех, у кого рейтинг отрицательный, либо вообще отдельных лиц по своему выбору), примерный алгоритм которого я когда-то рассматривал в отдельной теме, и публиковать его в метаданных капсулы.

Плюсы подхода

1) Автоматическая репликация, причём чем востребованнее сайт, тем больше копий будет.
2) Раздавать свои сайты-капсулы можно с любого устройства, даже мобильного устройства, и это не требует root-прав или специализированных знаний. (Отмечу, что для мобильных платформ, на мой взгляд, целесообразнее делать монолитное приложение вместо связки proxy+клиент.)
3) Лёгкие клиенты, т.к. для отображения Markdown нужно гораздо меньше ресурсов, чем для современного Web-броузера.
4) Исчезает необходимость регистрации, использования паролей (кроме опционального пароля для ключа), их восстановления через Email и т.п.
5) Privacy-friendly: вся идентификация пользователей построена на криптографических ключах без какой-либо привязки к каким-либо другим данным (Email, телефоны и прочее), нет cookies, клиентских скриптов и т.п. При скачивании сайта можно отследить разве что IP (и то можно сделать как в yggdrasil, что запрос проходит несколько промежуточных узлов). Но тут нужно помнить, что потенциально существует возможность отследить все комментарии с этого профиля-«домена» на других узлах и вычислить пользователя на основе им же самим написанной информации. Так что нужно следить за тем, чтобы не путать профили!
6) реализация принципа locale-first: копии просмотренных сайтов (или хотя бы их текстовая часть) будут доступны в оффлайне, включая даже те страницы, которые не открывались во время онлайна (удобно для чтения выложенных постранично книг и блогов). (Да, я верю, что рано или поздно человечество придёт к информационной гигиене, частью которой будет отключение связи на несколько часов в день, чтобы иметь возможность побыть в тишине и сосредоточенности.)
7) сохранение возможности общения в духе раннего Web 2.0, более широкий контроль за внешним видом сайтов, чем в Gemini, через метаданные страниц и/или зарезервированные адреса для настроек всего сайта. (Хотя уже сейчас в Gemini есть что-то вроде форумов, но из-за полного отсутствия какого-либо визуального оформления постов от их чтения быстро начинает кипеть мозг.)

Недостатки и риски

1) так же, как для yggdrasil или torrentов, нужен начальный список нод с белыми IP-адресами. Также отсутствие белого IP может быть причиной снижения скорости;
2) невозможно realtime-общение, комментарии и реакции могут приходить с задержкой;
3) отсутствие полнотекстового поиска (хотя вроде поиск по torrentам какой-то существует);
4) невозможность сделать закрытые разделы в капсуле (хотя отдачу самой капсулы по белому списку организовать можно, но при условии, что у получателей стоят proxy-приложения, которые будут соблюдать ограничения и не раздавать её дальше);
5) риск, что на вашем компьютере вместе с капсулой неожиданно окажутся нежелательные материалы из-за того, что создатель сайта зачем-то их выложил (типа книг, включённых в сами знаете какой список);
6) риск сквоттинга для последующей перепродажи красивых «доменных» имён;
7) невозможность восстановить контроль над «доменом» в случае утери ключа;
8) риск клонирования капсул на похожем «домене» (например, в мошеннических целях) — оно становится очень простой задачей;
9) риск массовой генерации ключей с целью DDoS-атак, троллинга, травли, спама. Потенциально этому можно противодействовать, сделав так, что каждый новый ключ должен быть подписан ключом действующего участника, который несёт определённую ответственность за действия того, кого он подписал (аналогично тому, как это было с нодами и пойнтами в FIDO) и чёрными списками тех, кто замечен в массовом подписании подобного (т.е. в чёрный список попадают их ключи и все подписанные ими), но лично я против подобного. Также частично этому может противодействовать рейтинг доверия из п.9;
10) проблема репликации маловостребованных сайтов-капсул, про которые просто никто не знает.

Ещё нашёл проект, где заявляются сходные цели: FEDAnet.
Хотя почитав, как автор проекта общается с пользователями на своём сайте, сильно сомневаюсь, что что-то хорошее из этого выйдет.