Децентрализованные социальные сети: критерии выбора протокола и скрытые риски

Проблема проявляется позже, когда платформа меняет правила, закрывает аккаунт, ломает ленту или превращает привычное действие в серию раздражающих экранов. Децентрализованные социальные сети обещают снять эту зависимость. Но в реальном онбординге быстро выясняется: «децентрализованная» — не характеристика удобства и не гарантия свободы. Это набор архитектурных компромиссов.

Я посмотрел на три модели, вокруг которых сегодня строится большая часть разговора о социальных протоколах: федеративный ActivityPub, событийный Nostr и AT Protocol с переносимыми репозиториями аккаунтов. Они решают похожую пользовательскую задачу — дать человеку больше контроля над идентичностью, контентом и выбором клиента, — но делают это совершенно разными путями.

Именно поэтому децентрализованные социальные сети и выбор протокола нельзя сводить к вопросу «какая сеть свободнее». Для автора, команды продукта, сообщества или просто пользователя полезнее спросить иначе: что будет с профилем при смене сервера? Кто реально доставит мой пост подписчикам? Можно ли убрать ошибочно опубликованные данные? Где включается модерация — и можно ли от неё отказаться, не потеряв ленту целиком?

Три архитектуры, три разных ощущения от продукта

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

ActivityPub: сеть серверов, которые договариваются друг с другом

ActivityPub — рекомендация W3C, опубликованная 23 января 2018 года. В ней описаны два слоя взаимодействия: клиент общается со своим сервером, а сервер доставляет действия другим серверам. Пользователь выбирает инстанс, создаёт там учётную запись, а дальше его посты и уведомления могут уходить в другие совместимые узлы.

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

Ожидание: сервер — просто техническая деталь, которую пользователь почти не замечает.

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

ActivityPub хорошо ложится на сообщества, которым нужна собственная площадка с понятными границами: редакции, тематические клубы, локальные группы, независимые авторские проекты. Здесь есть ощущение «своего дома», а федерация добавляет окно в более широкую сеть.

Но совместимость с протоколом не означает автоматической безопасности. В его модели отдельно учитываются спам, федеративные атаки на доступность, рекурсивные объекты и необходимость безопасно обрабатывать контент. Если продукт пишет на лендинге «поддерживаем ActivityPub», это ещё не ответ на вопрос, как он защищает ленту от мусора, ограничивает запросы и отображает потенциально опасные вложения.

Nostr: подписанные события и сеть ретрансляторов

В Nostr пользовательский контент устроен иначе. Базовый объект здесь — событие: в нём есть публичный ключ автора, время, тип, теги, содержимое и криптографическая подпись. Идентификатор события рассчитывается из канонически сериализованных данных, а подпись позволяет проверить, что публикацию действительно создал владелец соответствующего ключа.

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

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

Ожидание: раз пост подписан моим ключом, он всегда будет доступен в любом клиенте.

Реальность: подпись подтверждает происхождение события, но не заставляет ретранслятор хранить его вечно и не гарантирует доставку всей истории. Ретранслятор вправе ограничивать подключения по IP или клиенту. При подписке приложение может запросить определённое количество событий, но сервер имеет право вернуть меньше. Поэтому две программы с одним и тем же ключом могут показать разную глубину ленты, разные ответы и даже разную картину старых публикаций.

У Nostr есть несколько режимов хранения, и это важно понимать до публикации значимого контента:

1. Обычные события обычно сохраняются ретрансляторами, но конкретный оператор всё равно определяет политику хранения и доступа.

2. Заменяемые события предполагают, что важна последняя версия: старые варианты могут быть отброшены. Это удобно для профиля или актуального состояния, но плохо подходит для истории, которую хочется сохранить в полном виде.

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

Иными словами, Nostr удобно рассматривать не как «вечную стену постов», а как сеть доставки и обнаружения подписанных действий. Это сильная идея, но она требует от продукта честного UX: пользователь должен понимать, на каких ретрансляторах лежат его данные, что именно синхронизируется и почему старый пост внезапно не виден в новом клиенте.

Ключ даёт контроль над подписью и идентичностью, но не превращает чужие серверы в вечное хранилище.

AT Protocol: аккаунт как переносимый репозиторий

AT Protocol строит пользовательский путь вокруг другой модели. Авторитетное место для репозитория аккаунта — Personal Data Server, или персональный сервер данных. Текущий адрес такого сервера связан с DID — устойчивым идентификатором пользователя. Если человек мигрирует на другой PDS, DID-документ обновляют так, чтобы сеть понимала, где теперь находится его репозиторий.

Здесь есть очень здравая продуктовая мысль: человеку не обязательно быть навсегда привязанным к одному хостингу, чтобы сохранить свою идентичность. При этом привычное имя вроде name.example остаётся удобным слоем для общения, но не является главным техническим якорем. Handle может меняться. DID предназначен для долгосрочной идентификации.

На практике это выглядит как попытка разделить то, что в централизованных соцсетях обычно склеено в один ком: имя пользователя, база данных, сервер, клиент и правила видимости. В AT Protocol эти слои можно развести. И это полезно не только для идеологов Web3, но и для обычного автора, который не хочет терять аудиторию из-за смены провайдера.

Однако здесь тоже есть трение. Если приложение показывает пользователю красивый никнейм, а не объясняет, что за ним стоит DID, оно обязано корректно проверять связь между ними. Спецификация прямо предупреждает: нельзя считать handle действительным, пока DID не разрешён и не подтвердил эту двустороннюю привязку. Иначе появляется пространство для подмены имени, устаревших данных или просто неаккуратного отображения профиля.

Миграция тоже не равна мгновенному телепорту. После смены PDS сервисы с агрессивным кешированием могут не принимать служебную авторизацию до 24 часов. Для человека это выглядит просто: «я перенёс аккаунт, а часть функций пока ведёт себя странно». Хороший клиент должен не прятать это за бесконечным спиннером, а объяснять, что именно обновляется и сколько может занять переход.

Сравнение протоколов: где на самом деле живёт ваш аккаунт

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

Эта таблица не выбирает победителя, потому что универсального победителя здесь нет. Для небольшой тематической сети важнее предсказуемые правила сервера и сильная локальная модерация — это естественная территория федеративной модели. Для аудитории, которая уже умеет работать с ключами и ценит независимость от одного клиента, логичнее смотреть в сторону Nostr. Для продуктов, где критична переносимая идентичность и разделение аккаунта, хостинга и приложения, интереснее AT Protocol.

Сравнение Farcaster, Lens Protocol и других Web3-социальных платформ часто строят по принципу «какой проект более децентрализован». Это слабый вопрос. Куда полезнее разложить любой протокол на четыре пользовательских слоя: идентичность, хранение, доставку и модерацию. Тогда маркетинговое слово быстро превращается в понятную схему рисков.

Модерация никуда не исчезает — она просто меняет адрес

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

В ActivityPub серверы могут выбирать, с кем федераться, кого блокировать, какие правила применять к локальным аккаунтам. Это может быть плюсом: сообщество получает среду со своими нормами. Но пользователь должен понимать, что его охват и доступ к чужим публикациям зависят от отношений между операторами узлов, а не только от кнопки «подписаться».

В Nostr ретрансляторы тоже не обязаны принимать всё подряд. Они могут ограничить число подключений, отклонить событие или не выдать полную выборку по запросу. А клиент решает, какие ретрансляторы подключать и как собрать ленту из полученных данных. Свобода выбора здесь реальна, но за неё расплачиваются настройкой и неопределённостью. Мне потребовалось бы буквально несколько минут, чтобы подключить новый клиент; чтобы убедиться, что он показывает нужную историю и не пропускает важные события, потребуется уже осмысленная проверка.

AT Protocol интересен тем, что делает модерацию явно многослойной. Сеть может применять takedown-фильтры на уровне API, сервисы модерации — прикреплять метки, а пользователь — использовать mute и block. Метки имеют источник, выраженный через DID, и могут по-разному учитываться приложениями. В результате одна и та же публикация способна выглядеть по-разному в разных клиентах.

Это не баг, а свойство архитектуры. Но продукту придётся ответить на неудобный вопрос: кто определяет «безопасную ленту» по умолчанию? Если пользователь не видит этого выбора, децентрализация остаётся где-то под капотом, а правила ему всё равно назначает интерфейс.

В распределённой сети модерация не отменяется: она распадается на несколько решений, которые пользователь должен суметь увидеть и настроить.

Удаление поста — не магическая кнопка «стереть везде»

Самый болезненный участок для веб3 социальных платформ — не публикация, а удаление. В централизованном приложении кнопка «удалить пост» тоже не гарантирует исчезновение скриншотов, репостов и кешей, но пользователь хотя бы понимает, к кому предъявлять вопрос. В распределённой сети копий и операторов больше, а границы ответственности размываются.

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

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

AT Protocol отдельно оговаривает, что удаление записи или её удаление с собственного PDS не гарантирует очистку downstream-сервисов. Если другой сервис получил данные через Relay и не обрабатывает удаление по спецификации, копия может остаться у него. Это касается и записей, и потенциально связанных представлений: поисковых индексов, превью, архивов, кешей.

Здесь возникает не только пользовательская, но и правовая сложность. Статья 17 GDPR закрепляет право требовать удаления персональных данных без неоправданной задержки при определённых основаниях. Нельзя честно сказать, что любой протокол автоматически соответствует или не соответствует этому требованию: всё зависит от ролей участников, юрисдикции, типов данных и фактической обработки. Но можно сказать уверенно: продукт, который не объясняет маршрут удаления, репликацию и работу с копиями, перекладывает риск на пользователя.

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

Что тестировать до того, как строить сообщество или переносить аудиторию

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

• Создайте тестовый профиль и выясните, чем он является технически. Это аккаунт на сервере, пара ключей или репозиторий с DID? Где показывается резервная информация и можно ли восстановить доступ без поддержки конкретной компании?
• Опубликуйте несколько типов контента. Обычный пост, отредактированную запись, изображение, ссылку. Затем откройте их в другом клиенте или через другой узел. Это быстро показывает, насколько обещанная совместимость работает за пределами демо.
• Смените клиент, а в доступной тестовой среде — и хостинг. Не нужно ждать аварии, чтобы впервые читать инструкцию по миграции. Посмотрите, переносятся ли профиль, подписки, публикации и вложения, а также как сервис ведёт себя во время кеширования.
• Попробуйте удалить публикацию. Проверьте не только исчезновение из собственного профиля, но и выдачу в другом клиенте, поиск, уведомления и сохранённые превью. Если продукт не объясняет ограничения, это уже ответ.
• Настройте модерацию от лица обычного пользователя. Найдите mute, block, фильтры, источники меток, настройку ретрансляторов или правила сервера. Если для базовой защиты ленты нужно понимать внутреннюю архитектуру, онбординг пока не справился со своей работой.
• Посмотрите на поведение без идеального интернета. Не все операции обязаны быть мгновенными. Но приложение должно ясно сообщать, пост уже подписан, отправлен на сервер, ожидает синхронизации или не доставлен вообще.

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

Вердикт: выбирать нужно не «самую свободную», а самую понятную модель контроля

ActivityPub, Nostr и AT Protocol не стоят на одной линейке от плохого к хорошему. Они по-разному распределяют ответственность между пользователем, оператором инфраструктуры и приложением.

ActivityPub я бы выбирал там, где важны зрелая федеративная логика, автономия сообществ и понятная роль сервера. Nostr — когда команда сознательно строит опыт вокруг ключей, подписанных событий и выбора ретрансляторов, не обещая пользователю невозможной бесшовности. AT Protocol — когда продукту нужна переносимая идентичность и возможность отделить аккаунт от одного конкретного хостинга, но есть готовность аккуратно провести человека через DID, handle, миграцию и кеши.

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

Хорошая децентрализованная соцсеть не заставляет пользователя изучать спецификации. Она честно показывает, где лежит аккаунт, кто хранит посты, как меняется клиент, кто фильтрует контент и почему удаление не всегда означает исчезновение. Вот это и есть тот UX, ради которого распределённые протоколы вообще стоит превращать в работающие приложения.