В последние годы децентрализованные социальные сети стали привлекать всё больше внимания, обещая свободу, устойчивость и независимость от больших корпораций. Среди таких проектов Bluesky изначально позиционировался как новаторская платформа, разработанная с упором на децентрализацию и участие пользователей в управлении своей информацией. Однако недавний инцидент с единовременным падением всех основных пользовательских серверов (PDS) Bluesky, вызвавший часовой простой сервиса, заставил многих экспертов и пользователей усомниться в степени реальной децентрализации этой платформы. Разберёмся, почему столь масштабный сбой одновременно затронул все серверы, и почему Bluesky на практике остаётся сильнее централизованным проектом, чем многие другие социальные сети с распределённой архитектурой. В отличие от классических децентрализованных платформ, таких как Mastodon, где независимые серверы взаимодействуют между собой и управляются разными сообществами и организациями, Bluesky использует уникальный подход — архитектуру, где есть один центральный сервис, именуемый «relay» (ретранслятор).
Именно через него координируется обмен данными между многочисленными персональными дата-серверами (PDS), которые хранят пользовательскую активность и персональные данные. Идея заключается в том, что пользователи могли бы выбирать между использованием серверов, управляемых самой компанией Bluesky, либо запускать собственные PDS, устанавливая максимальный контроль над своими данными и креативностью. Таким образом, хоть и предполагается распределённость и децентрализация в классическом понимании, ключевая технология, обеспечивающая связность всех элементов экосистемы, по-прежнему опирается на один центральный элемент — relay. Недавний инцидент произошёл 24 апреля 2025 года, когда произошёл масштабный ддос-атак на всю инфраструктуру Bluesky, в первую очередь на PDS, которые находятся в управлении компании. Публичные данные свидетельствуют, что атака вызвала одновременное прекращение работы всех корпоративных пользовательских дата-серверов.
Несмотря на то что пользователи, самостоятельно запустившие свои PDS, не пострадали от сбоя, сервис для большинства, подключённых к BS-управляемым серверам, оказался недоступен на несколько часов. Этот факт вызвал бурные обсуждения в профессиональном сообществе и среди экспертов децентрализации. Ведь одна из фундаментальных идей децентрализованных сетей состоит именно в том, что отказ части сети не приведёт к падению всей системы. В случае Bluesky же одновременно вышла из строя большая часть критической инфраструктуры, несмотря на распределённость серверов. Аналитики отмечают, что при всём параде децентрализации в архитектуре Bluesky всё же наблюдается уровень зависимости от единого центра — ретранслятора (relay), который играет роль основного коммуникатора и маршрутизатора сообщений между PDS.
Если этот сервис функционирует, и хотя бы некоторые PDS остаются онлайн, пользователи сохраняют способность взаимодействовать между собой. Тем не менее, основной удар пришёлся по инфраструктуре самой компании, где все её PDS оказались под влиянием атаки одновременно. Теоретическая возможность одновременного ддос-атака на несколько географически распределённых PDS, управляемых одной организацией, технически присутствует. Ведь если все эти сервисы размещены в единой облачной инфраструктуре или зависят от единых систем защиты и маршрутизации трафика, атака может единым ударом вывести их из строя. Значит, несмотря на распределённость по физическому или логическому признаку, централизованное управление создаёт потенциальную точку отказа.
Сообщество активно обсуждает версии произошедшего. Состоялась переписка с техническим директором Bluesky, Полом Фрэйзи, который подтвердил факт ддос-атаки и отметил, что её источник вероятно связан с третьей стороной — по всей видимости, случайной, а не злонамеренной. Впрочем, окончательные подробности инцидента компания пока раскрывать не стала, ссылаясь на продолжающееся расследование и решения о новых мерах безопасности. Интересно отметить реакции экспертов, разработчиков и пользователей, которые раскритиковали попытки компании позиционировать Bluesky как полностью децентрализованную платформу. Для сравнения, Mastodon и подобные ему проекты строятся из независимых серверов, каждый из которых является равноправной единицей, способной автономно развиваться и выживать даже при отключении соседних нод.
Это именно то, что многие называют настоящей децентрализацией, а не наличием единой центральной службы ретрансляции. В ответ на критику топ-менеджеры Bluesky указали на особенности протоколов, используемых в современных социальных сетях, и отметили, что ActivityPub, применяемый Mastodon, имеет проблемы с масштабированием при серьёзной нагрузке. По их мнению, архитектура Bluesky должна решать эти задачи иначе, за счёт гибридного подхода с центральным элементом и распределёнными серверными узлами. Тем не менее, ощущения от реального сбоя показывают, что архитектура Bluesky, хоть и предлагает компоненты децентрализации, на практике выглядит как система с уязвимым центральным звеном. Именно это может стать основной препоной для тех, кто ищет по-настоящему свободные и устойчивые решения без единой точки отказа.
В целом, описанный случай с Bluesky демонстрирует сложность и многогранность темы децентрализации в современных социальных платформах. Технические и организационные аспекты тесно переплетаются с пользовательскими ожиданиями, вопросами масштабируемости и безопасностью. Несмотря на объявленную концепцию открытости и распределённости, удержать баланс между надежностью, удобством и независимостью остаётся серьёзным вызовом для любого проекта. Сравнивая Bluesky с более традиционными системами, такими как Mastodon и другими платформами федеративного интернета (данными проектами охватывается широкий круг независимых серверов, развиваемых разными сообществами), видно, что окончательная проверка «на децентрализацию» происходит лишь при масштабных стресстестах и критических инцидентах. Как показал апрельский сбой, архитектурные особенности Bluesky вынуждают говорить о более централизованном характере сервиса, что важно учитывать и пользователям, и инвесторам.
