Состояние децентрализованного веба в 2026 году

Социальная сеть децентрализована в практическом смысле тогда, когда пользователь может сменить провайдера, не потеряв свою личность, свои данные или своих подписчиков, и ActivityPub, AT Protocol и Solid — каждый из них проходит лишь часть этой проверки.

Выбрать сервер и подписаться на пару аккаунтов — это самое простое. Словарь, который приходит вместе с этими сетями (PDS, relay, AppView, Pod, WebID), накапливается стремительно, и ничего из этого не имеет особого значения до того дня, когда вы захотите переехать.

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

Что на практике означает «децентрализованный»?

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

Каждый протокол ниже оценивается по этому тесту, а не по количеству существующих серверов или по тому, кто написал софт. Число серверов говорит об отказоустойчивости. Тест из трёх частей говорит о привязке к поставщику (lock-in).

Как ActivityPub федерирует инстансы между собой?

ActivityPub, имеющий статус W3C Recommendation с 23 января 2018 года, федерируется за счёт того, что каждый сервер доставляет активности пользователя напрямую в inbox’ы серверов, на которых размещены подписчики этого пользователя. Каждый пользователь — это актор с inbox и outbox; публикация записывает в ваш outbox, а ваш сервер отправляет POST-запрос с активностью в inbox каждого подписчика. Централизованного индекса нет — только серверы, пересылающие JSON друг другу.

Mastodon, Pixelfed, Lemmy и PeerTube реализуют этот протокол, поэтому аккаунт в Mastodon может подписаться на канал PeerTube или сообщество Lemmy.

Личность — это то, где тест не проходит. Хэндл вида @user@instance.example принадлежит инстансу, поэтому аккаунт, который не был перенесён до отключения сервера, нельзя восстановить где-либо ещё. Перенос аккаунта в Mastodon отправляет активность Move, которая переводит подписчиков на новый аккаунт, но документация прямо говорит: всё, что вы публиковали, остаётся на прежнем месте, а архив, который можно скачать, нельзя загрузить в другой аккаунт Mastodon. Оценка по тесту: аудитория переживает запланированный переезд, данные частично сохраняются в виде экспорта, личность не сохраняется вовсе.

AT Protocol: переносимая личность, сконцентрированная инфраструктура

В AT Protocol личность пользователя — это DID, которым не владеет ни один сервер, а его посты, подписки и профиль живут в Personal Data Server (PDS), который можно перенести к другому хостеру без изменения DID. Над PDS находятся relay, которые обходят все PDS и выдают единый firehose, и AppView, которые индексируют этот firehose в продукт, отображаемый клиентом. Спецификация публикуется и поддерживается компанией Bluesky Social PBC.

У переносимости есть границы. Официальное руководство по миграции аккаунта описывает эти шаги как нечто, находящееся за пределами собственно протокола и способное измениться в дальнейшем, и отправляет вас к CLI goat или к инструменту от сообщества, а не к процессу внутри приложения. Брайан Ньюболд, инженер протокола в Bluesky, писал в октябре 2025 года, что перенос аккаунта работает в живой сети с начала 2025 года, но остаётся задачей для разработчиков, и что PDS-хосты, которые запускает Bluesky, не принимают входящие переносы аккаунтов.

Второе уточнение — операционное. Transparency Report Bluesky за 2025 год сообщает, что компания держит больше аккаунтов, чем кто-либо другой, и что именно там регистрируется большинство людей, тогда как остальная часть сети распределена по тысячам Personal Data Servers, большинство из которых управляются другими людьми. Официальных данных о том, какая доля сети проходит через relay и AppView, которыми управляет Bluesky, нет. Критики утверждают, что независимые PDS-хосты и инфраструктурные проекты сообщества по-прежнему опираются на основные сервисы, управляемые Bluesky, и некоторые из них заключают, что сеть на практике не децентрализована; это оценочное суждение, а не измерение. Оценка по тесту: личность и данные по замыслу переживают смену провайдера, подписчики переходят вместе с вами, поскольку записи о подписках ссылаются на DID, а уровни выше PDS остаются в основном в руках одной компании.

Solid: поды данных без потребительского рынка

Solid хранит данные пользователя в Pod’е, которым управляет сам пользователь, и требует, чтобы каждое приложение запрашивало доступ. WebID идентифицирует человека, Pod — это HTTP-сервер, хранящий RDF-ресурсы, а приложения читают и записывают эти ресурсы, когда правила авторизации это разрешают. По тесту на смену провайдера у Solid самая чистая архитектура из трёх: личность, данные и правила доступа — всё остаётся у пользователя, а приложение — всего лишь клиент.

Внедрение не соответствует архитектуре. Solid Protocol — это черновик W3C Community Group (v0.11.0, 12 мая 2024 года), а не стандарт W3C, и индекс TR показывает, что с тех пор новых версий не публиковалось; предыдущими релизами были 0.9.0 (декабрь 2021) и 0.10.0 (декабрь 2022), а работа над 0.12.0 находится в черновике редактора. Спецификации расширений, от которых зависят приложения — WebID Profile, Type Indexes и Application Interoperability — всё ещё остаются черновиками, а спецификация допускает две несовместимые системы авторизации, WAC и ACP, причём серверы вправе реализовать любую из них. Инструментарий и документация отстают от обоих других протоколов.

Практическое препятствие — где зарегистрироваться. На solidproject.org перечислено около пятнадцати хостинг-сервисов для подов, большинство из них небольшие или экспериментальные, а Inrupt, компания, соучредителем которой стал Тим Бернерс-Ли, сейчас продвигает корпоративную инфраструктуру кошельков для бизнеса. Разработчик Solid-приложений Ноэль Де Мартин в 2024 году назвал отсутствующий потребительский рынок подов главным, что тормозит Solid: просьба «войдите через Solid» сначала отправляет человека искать провайдера, и именно на этом большинство останавливается.

Сколько пользователей у Bluesky и Mastodon?

В Transparency Report Bluesky за 2025 год (29 января 2026) насчитано 41,41 млн аккаунтов на конец 2025 года — против 25,94 млн ранее — с учётом как аккаунтов на хостинге Bluesky, так и независимых PDS; компания отслеживает, но не публикует показатель ежемесячно активных пользователей. Отчёт нормализует данные о модерации на 1000 ежемесячно активных пользователей, не указывая при этом знаменатель.

Mastodon публикует собственный показатель по всей сети на странице серверов на joinmastodon.org, а сторонние трекеры, опрашивающие API статистики инстансов, публикуют свои. Цифры не совпадают. TechCrunch сообщал в феврале 2026 года, что собственный сайт Mastodon давал около 785 000 ежемесячно активных, тогда как трекеры показывали от примерно 750 000 до миллиона — в зависимости от того, к какому обратиться. Эти же трекеры оценивают число зарегистрированных аккаунтов примерно в 10 млн на приблизительно 10 000 серверах, хотя итоговые суммы расходятся между трекерами на миллион и более в зависимости от того, как каждый из них учитывает серверы, которые перестали отвечать.

Регистрации и активные пользователи в Mastodon различаются на порядок, а у Bluesky это соотношение неизвестно. Сравнение, в котором регистрации одной сети сопоставляются с активными пользователями другой, сравнивает разные величины.

Что можно создать на ActivityPub, Solid и Bluesky?

Все три протокола — это обычный HTTP, поэтому для их изучения достаточно терминала:

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

WebFinger — это RFC 7033 и соглашение экосистемы Mastodon, а не часть самого ActivityPub. Serverы Solid обязаны по запросу отдавать RDF-ресурсы в формате Turtle или JSON-LD.

Самый доступный проект — пользовательская лента Bluesky. Custom feed в Bluesky — это HTTP-сервис, возвращающий упорядоченный список URI постов; AppView сам получает и отображает эти посты, поэтому сервису ленты никогда не требуется хранить или отдавать контент постов. Требуются два XRPC-маршрута, а лексикон getFeedSkeleton определяет параметры (feed, limit до 100, cursor) и ошибку UnknownFeed:

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

Курсор непрозрачен для AppView и полностью находится в вашем распоряжении; для фиксированного списка достаточно индекса позиции, а официальный туториал рекомендует составной курсор «timestamp + CID», когда посты приходят из живого индекса. Для запуска в продакшн вы разворачиваете сервис по HTTPS, публикуете DID-документ, указывающий на этот хост (стартовый набор по умолчанию настраивает его как did:web), и запускаете его скрипт publishFeedGen.ts, чтобы создать запись app.bsky.feed.generator в собственном репозитории. После этого лента появляется в приложении Bluesky, как любая другая.

Итоговая картина

По тесту на смену провайдера ActivityPub переносит подписчиков, но не личность; AT Protocol на бумаге переносит все три компонента, но большая часть сети по-прежнему идёт через relay и AppView одной компании; Solid в принципе переносит всё, но не имеет потребительского рынка, который бы это обеспечил. Выбирайте протокол, с чьим режимом отказа вы готовы жить, а затем потратьте выходные на генератор лент, описанный выше: это самый короткий путь от чтения о децентрализованном вебе к запуску его собственного фрагмента.

Часто задаваемые вопросы

Могут ли пользователи Bluesky и Mastodon подписываться друг на друга?

Нативно — нет: ActivityPub и AT Protocol не совместимы между собой, поэтому кросс-сетевые подписки идут через мост. Bridgy Fed, который управляется некоммерческой организацией A New Social, работает по принципу opt-in: пользователь Bluesky подписывается на @ap.brid.gy, а пользователь федиверса — на @bsky.brid.gy@bsky.brid.gy. Проброшенные аккаунты выглядят как user.instance.ap.brid.gy в Bluesky и как handle@bsky.brid.gy в федиверсе. Пробрасываются только полностью публичные посты, а посты из федиверса длиннее 300 символов обрезаются в Bluesky.

В чём разница между did:plc и did:web в AT Protocol?

AT Protocol поддерживает только два метода DID. did:plc, разработанный Bluesky Social PBC, регистрирует идентификаторы в каталоге PLC, поддерживает ротацию и восстановление ключей и создаётся официальным установщиком PDS для новых аккаунтов. did:web выводит идентификатор из контролируемого вами хостнейма, допускает только идентификаторы уровня хостнейма без путей и не предусматривает восстановления в случае потери домена, поэтому подходит для сервисов вроде генераторов лент.

Можно ли использовать собственный домен в качестве хэндла в Bluesky, не хостя PDS?

Да. Хэндл — это DNS-хостнейм, двусторонне связанный с вашим DID, и эта связь не зависит от того, какой PDS хранит ваши данные. Опубликуйте DID в одном из двух мест: в DNS TXT-записи с именем _atproto.yourdomain и значением did=, за которым следует ваш полный DID, либо в виде текстового ответа по адресу https://yourdomain/.well-known/atproto-did. Спецификация рекомендует DNS-метод для частных лиц; HTTPS-метод рассчитан на крупные сервисы.

Если я разверну Personal Data Server самостоятельно, смогу ли я по-прежнему пользоваться приложением Bluesky?

Да. Официальный PDS поставляется как Docker-образ для VPS с публичным IPv4-адресом, wildcard-записью DNS и открытыми портами 80 и 443; Bluesky рекомендует 1 ГБ RAM и 20 ГБ дискового пространства на 1–20 пользователей. Для входа укажите URL вашего PDS в приложении. Конфигурация по умолчанию указывает на AppView, relay и каталог PLC, принадлежащие Bluesky, поэтому выше уровня данных PDS по-прежнему зависит от сервисов, управляемых Bluesky.