Опубликовано: 28.09.2026 | Источник: TechCrunch

## Семантический анализ **Основной запрос:** децентрализованные социальные сети в ВКР / Mastodon в дипломе **LSI-запросы:** протокол ActivityPub, федерация и федеративные инстансы, Fediverse, WebFinger, actor-модель, REST API и OAuth 2.0, горизонтальное масштабирование, очередь доставки (fan-out), PostgreSQL + Redis, микросервисная архитектура, Ruby on Rails / Node.js. **Реальные вопросы студентов:** «Нужно ли писать код, или хватит проектирования?», «Как измерить производительность федеративного сервиса?», «Где брать данные для расчётов и экспериментов?», «Как обосновать выбор стека, а не просто перечислить библиотеки?», «Обязательны ли UML-диаграммы и по какому стандарту их оформлять?» **Ключевые сущности:** ГОСТ 34.602-89, ГОСТ 19.402-78, ISO/IEC 25010, W3C ActivityPub, Kubernetes, OpenTelemetry, CI/CD-пайплайн, k6/Locust. ---

Децентрализованные соцсети в дипломе: Mastodon, ActivityPub и архитектура федерации

26 марта 2026 года Mastodon объявил о редизайне профилей пользователей: интерфейс упростили, чтобы платформа перестала выглядеть «для гиков» и стала понятной массовой аудитории и организациям. Новость сама по себе продуктово-дизайнерская, но за ней стоит куда более интересная инженерная тема. Mastodon — это федеративная сеть на протоколе ActivityPub, где нет единого центра, данные живут на независимых инстансах, а контент расходится между ними асинхронно. Для выпускника ИТ-направления это готовая ниша для ВКР: распределённые системы, протоколы обмена, идентичность, модерация, отказоустойчивость. Пока однокурсники пишут очередную CRUD-«систему учёта заявок», вы можете защищать работу по архитектуре федерации — и выглядеть на защите убедительнее.

Три темы ВКР, которые вытекают из новости

Тема 1. Сервис федеративного обмена публикациями на ActivityPub

Актуальность. Редизайн Mastodon — сигнал, что аудитория федеративных сетей растёт, а значит растёт нагрузка на доставку контента между инстансами. Классические монолитные решения здесь не масштабируются.

Цель: спроектировать и реализовать модуль асинхронной доставки активности между инстансами с гарантией «at-least-once».

• Проанализировать спецификацию W3C ActivityPub и модель actor;
• спроектировать схему БД для хранения подписок, очередей и статусов доставки;
• реализовать retry-политику с экспоненциальной задержкой и dead-letter-очередью;
• провести нагрузочное тестирование и снять метрики задержки.

Структура: Глава 1 — анализ протоколов федерации и существующих реализаций; Глава 2 — проектирование архитектуры, схемы данных, диаграммы последовательности; Глава 3 — реализация, нагрузочные испытания, расчёт затрат на инфраструктуру.

Тема 2. Миграция пользовательского профиля между инстансами

Актуальность. Упрощение профилей в Mastodon снижает порог входа, но ключевой страх новичка — «а что если мой сервер закроется?». Переносимость аккаунта — прямая техническая задача, вытекающая из статьи.

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

• изучить механизм переадресации actor через поле movedTo;
• спроектировать протокол подтверждения владения аккаунтом;
• обеспечить консистентность данных при частичном сбое миграции;
• оценить RTO/RPO процесса переноса.

Структура: теория идентичности в распределённых системах → архитектура сервиса миграции → тестирование сценариев отказа.

Тема 3. Распределённая модерация и репутация в Fediverse

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

Цель: построить сервис обмена списками блокировок и репутационными оценками между инстансами.

• формализовать модель доверия между администраторами;
• спроектировать API обмена «чёрными списками»;
• защитить механизм от злоупотреблений и накрутки;
• оценить производительность при пиковых всплесках трафика.

Аналитическая глава: как обосновать выбор, а не перечислить мод

Самая частая слабость первого раздела — «список технологий без критериев». Работайте от требований к системе, а не от личных предпочтений. Отправная точка — нефункциональные требования по ISO/IEC 25010: производительность, отказоустойчивость, переносимость, удобство сопровождения. Дальше строите матрицу сравнения.

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

Проектная часть: от диаграммы к коду

Минимальный набор артефактов, который ожидает комиссия: контекстная диаграмма (ГОСТ 34.602-89 в терминах потоков данных), компонентная схема, ER-модель, диаграмма последовательности для ключевого сценария и спецификация API. Ключевой сценарий федерации выглядит так:

Клиент -> Инстанс A: POST /api/v1/statuses (публикация)
Инстанс A -> PostgreSQL: запись статуса
Инстанс A -> Redis/Sidekiq: постановка задачи доставки
Worker -> Инстанс B: POST /users/{name}/inbox (Activity, подпись HTTP Signature)
Инстанс B -> 202 Accepted
Инстанс B -> Верификация подписи -> запись -> fan-out подписчикам

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

Развёртывание и CI/CD

Если работа предполагает практическую часть, контейнеризация через Kubernetes даёт готовый материал для третьей главы: манифесты, horizontal pod autoscaler по длине очереди, health-пробы. В дипломе достаточно одного узла k3s, но схема должна показывать путь к масштабированию — это и есть защита архитектурного решения.

Тестирование и метрики: чем доказать, что работает

Самый уязвимый раздел. «Система работает быстро» без цифр — минус балл. Введите конкретные измеримые показатели и соберите их инструментами.

• Latency доставки — p50/p95/p99 времени от постановки в очередь до подтверждения по inbox.
• Успешность доставки — доля активностей, подтверждённых с первой попытки.
• Пропускная способность — количество исходящих активностей в секунду при заданном парке инстансов.
• RTO/RPO — восстановление после падения очереди или реплики БД.
• Нагрузочный профиль — сценарии в k6 или Locust: 100, 500, 1000 виртуальных пользователей.

Инструментарий удобно замкнуть на OpenTelemetry: трейсы по цепочке «API → очередь → воркер → внешний инстанс» дают красивые графики, которые сразу идут в приложение к диплому. Это ровно тот артефакт, который отличает инженерную работу от реферата.

Чему вы научитесь на такой работе

• Читать и применять спецификации уровня W3C, а не только документацию фреймворка.
• Обосновывать стек через нефункциональные требования и критерии, а не через «мне нравится Rails».
• Проектировать асинхронные взаимодействия: очереди, ретраи, идемпотентность, dead-letter.
• Снимать и интерпретировать метрики производительности, строить отчётные графики.
• Оформлять техническую документацию по государственным стандартам — навык, который пригодится в реальных проектах.

Вопросы, которые чаще всего задают перед началом

Нужно ли писать код, или можно ограничиться проектированием?

Зависит от требований кафедры. Если работа исследовательская — достаточно прототипа на 2–3 ключевых сценария (публикация, доставка, приём). Полноценная федерация с модерацией и UI в рамках ВКР почти никогда не нужна: комиссия оценивает инженерную корректность решения, а не полноту продукта.

Где взять данные для экспериментов, если нет реальных инстансов?

Поднимите два-три экземпляра Mastodon локально в Docker Compose и направьте их друг на друга. Генерацию активности делайте синтетическими скриптами. Такой стенд полностью воспроизводим, а его конфигурацию можно описать в приложении к диплому.

В каком нотации оформить UML-диаграммы, если кафедра не даёт указаний?

Используйте UML 2.5 для диаграмм последовательности и компонентов, а контекстную схему системы удобнее рисовать в нотации IDEF0 или в терминах ГОСТ 34.602-89. Главное — единообразие: все схемы должны читаться по одной логике и иметь легенду.

Насколько это вообще сложно по сравнению с типовыми темами?

Порог входа выше: нужно разобраться с протоколом и асинхронной доставкой. Зато тема свежая, конкурентов на защите почти нет, а материал легко подкрепить актуальной публикацией от 26 марта 2026 года — что снимает вопрос «а почему именно эта тема».

Чек-лист перед сдачей

Источник: Mastodon is making its decentralized social network easier to use with its latest revamp (опубликовано 2026-03-26)