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

Введение: Ахиллесова пята централизованных платформ

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

1. Блокировка ноды. Отключение или арест серверов в конкретной юрисдикции (как это периодически происходит с крупными сервисами в России, Иране или Бразилии) приводит к тому, что пользователь теряет доступ к аккаунту и вынужден «начинать с нуля».

2. Подмена данных. Администратор сервера или хакер, получивший доступ к БД, может технически подменить содержимое новости или «тихо» отредактировать сообщение задним числом.

3. Приватность по доверенности. Мы вынуждены верить платформе на слово, что она не читает нашу переписку и не сливает метаданные третьим лицам.

Идея Контейнерно-ориентированной P2P-архитектуры (Containerized Semantic Messaging Architecture, CSMA) предлагает отказаться от «звезды» в пользу «поля одуванчиков», где каждый объект данных — самостоятельная сущность со вшитым иммунитетом к подделке.

Идеология: Три слоя цифрового суверенитета

CSMA базируется на принципе разделения данных и транспорта. Пользователь владеет не аккаунтом в приложении, а Контейнером.

1. Контейнер как атомарная единица. В отличие от записи в таблице SQL, контейнер — это самодостаточный файл (blob), состоящий из:

• Заголовка (Envelope): Метаданные для маршрутизации (ID получателя, TTL, тип).

• Печати (Seal): Криптографическая подпись, вшитый хеш автора и временная метка.

• Полезной нагрузки (Payload): Зашифрованные или открытые данные.

2. Парковки вместо Дата-центров. Вместо привязки к IP-адресу сервера, контейнеры хранятся на Парковках и Депо.

• User Pod Parking: Легковесная нода, которая только держит ваш зашифрованный профиль и «почтовый ящик» для входящих. Она не хранит историю.

• Content Depot: Тяжелое хранилище для файлов и статей, работающее по принципу торрент-трекера.

3. Семантическая маршрутизация. Сеть не знает, что лежит в запечатанном контейнере, но знает куда его доставить. При смене провайдера пользователь публикует в DHT-таблицу сети обновленный маршрут: «Мой контейнер переехал на Парковку B». Для отправителя сообщений ничего не меняется — сеть сама найдет новый путь.

Архитектура протокола: Как это работает под капотом

Для понимания взаимодействия компонентов рассмотрим жизненный цикл отправки важного документа с гарантией авторства.

Шаг 1. Создание контейнера. Клиентское приложение (Alice) формирует файл с документом. Вместо того чтобы грузить его на сервер получателя, клиент:

1. Шифрует содержимое ключом получателя (Bob).

2. Вычисляет уникальный хеш содержимого (SHA-256).

3. Создает Document Capsule, где в слой «Печать» вшивается подпись Alice, связывающая хеш файла и её публичный ключ.

Шаг 2. Публикация и Уведомление.

• Тяжелая Document Capsule отправляется в ближайшее доступное Депо-хранилище (или несколько для надежности).

• В чат с Bob отправляется легкая Message Capsule, содержащая только ссылку на хеш документа: «Документ X7g9a... ждет тебя в сети».

Шаг 3. Получение и Верификация.

• Bob получает уведомление. Его клиент видит ссылку на хеш X7g9a....

• Клиент Bob опрашивает DHT-сеть: «У кого есть данные с хешем X7g9a...?».

• Сеть отвечает: «У Alice (если она онлайн) или на Депо в Москве».

• Клиент Bob скачивает байты с ближайшего пира (даже если сервер Alice уже отключили).

• Критический момент: Перед открытием файла клиент Bob сверяет подпись в слое «Печать» с публичным ключом Alice. Если хеш файла совпал, а подпись валидна — на экране загорается зеленый индикатор: «Авторство подтверждено криптографически». Подделать такой документ на транзитном узле невозможно физически.

Типизация контейнеров: Не всё то золото, что блестит

Ключевое преимущество CSMA — полиморфизм. Протокол един, но поведение объекта зависит от его класса. Это решает проблему избыточности для личных сообщений и недостаточной строгости для публикаций.

Области применения: От полевой кухни до госархива

Гибкость идеологии «контейнеров» позволяет масштабировать решение от личных нужд до государственных задач.

1. Гражданский сектор: Антидот от эпохи фейков. В эпоху дипфейков и сгенерированных скриншотов Article Capsule становится гарантом подлинности. Читатель видит не просто текст на сайте, а файл с «цифровой печатью». Если СМИ редактирует новость, оно обязано создать новую версию контейнера со ссылкой на старую. «Тихое переписывание» истории становится технически невозможным.

2. Бизнес и IoT: Суверенные данные. Технология Solid Pods (концептуально близкая к CSMA) уже тестируется в Европе (проект Athumi). Банк или больница не копят ваши данные в своем ЦОДе, а запрашивают временный доступ к вашему персональному контейнеру данных. Вы в любой момент видите, кто и зачем заходил в ваш «цифровой сейф», и можете отозвать разрешение.

3. Государственные структуры: Федеративная сеть без единой точки отказа. В госсекторе остро стоит вопрос юрисдикции данных и отказоустойчивости. CSMA позволяет каждому ведомству поднять свой Кластер Парковок. Минобороны, МЧС и Минздрав могут обмениваться контейнерами по федеративным «магистралям», но при этом данные не покидают доверенный контур. В случае чрезвычайной ситуации (отключения ЦОДа в регионе) контейнеры губернатора или штаба автоматически переезжают на резервную мобильную Парковку, сохраняя идентификаторы и связь.

Идея не нова и так или иначе ее пытались реализовать

Farcaster и Bluesky — два захода на децентрализованный соцграф.

Farcaster делал ровно то, о чём мы говорим: аккаунт как собственность, соцсвязи на блокчейне, клиенты отдельно. Меняешь приложение — подписчики остаются с тобой. В пике проект оценивали в $10 млрд. В 2025-м основатель Дэн Ромеро публично признал: «Мы пытались 4,5 года, не сработало». Соцсеть свернули, ушли в криптокошельки.

Bluesky с их AT Protocol до сих пор на плаву. Можно поднять свой PDS, забрать данные, уйти на другой клиент. Звучит знакомо. На практике — почти 100% пользователей сидят на серверах самой Bluesky. Поднять свой узел стоит сотни долларов в месяц. Этим занимаются считанные гики.

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

Solid Pods Тима Бернерса-Ли — самая близкая к нашей концепции вещь.

Личные контейнеры для данных. Приложения запрашивают доступ, а не хранят всё у себя. Красиво. Крупнейший публичный под продержался несколько лет. Статистика: 50-100 тысяч регистраций, активных пользователей — меньше сотни в день. Люди регистрировались, ломались об авторизацию, теряли ключи и никогда не возвращались. Сложность управления ключами убила проект. Пока восстановление доступа не станет проще, чем кнопка «забыл пароль» в Gmail, массового adoption не будет.

Status.im — когда в один флакон запихнули вообще всё.

P2P-мессенджер на Ethereum, без центральных серверов, со встроенным криптокошельком. Деньги, сообщения, DApps, децентрализация — полный набор. Проект живёт с 2020 года, прошёл аудиты безопасности, технически грамотный. Массового пользователя нет. В обзорах пишут: «хорошая идея, но сыро, тормозит, непонятно зачем обычному человеку». Урок: не надо пихать всё сразу. Модульность — наше всё.

Mastodon и ActivityPub — единственный работающий пример федерации.

Можно выбрать сервер по душе или поднять свой. Федерация живёт, люди общаются. Но есть две ложки дёгтя. Первая: при переезде на другой сервер вы теряете историю постов. Подписчики переезжают, контент — нет. Это ровно та проблема, которую наша модель User Pod решает: контейнер с историей путешествует вместе с вами. Вторая: де-факто централизация. Огромная доля пользователей сидит на mastodon.social, которым владеет сама Mastodon GmbH. Формально федерация, по факту — один большой сервер и россыпь маленьких.

Что из этого следует.

Все эти проекты не были ненужными. Споткнулись они не о технологию, а о человеческую природу и экономику: пользователю плевать на суверенитет, пока работает Telegram; любой геморрой с ключами убивает продукт; децентрализация стоит денег, и кто-то должен за неё платить.

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

Отдельно стоит отметить Delta Chat — мессенджер, который прикидывается почтой

Delta Chat стоит особняком. Это не новый протокол и не федерация серверов. Это слой поверх старого доброго email.

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

В чём сила. Delta Chat работает там, где всё остальное заблокировано. Если в стране оставили только доступ к почтовикам из «белого списка» — Delta Chat продолжает работать. Чат-серверы (chatmail) — лёгкие почтовые серверы, заточенные под мессенджер — можно поднять за полчаса. Порог входа минимальный: бабушка, умеющая пользоваться почтой, освоит Delta Chat за вечер.

Где архитектурные ограничения. Первое: ваш идентификатор — это почтовый адрес. Потеряли доступ к ящику — потеряли аккаунт. Второе: групповые чаты работают через email-рассылки. Метаданные группы — кто участник, кто когда зашёл — видны почтовому провайдеру. Третье: SMTP/IMAP не проектировались для мгновенного обмена сообщениями. Доставка может идти секунды или минуты. Вложения ограничены размером, который принимает почтовый сервер получателя.

Delta Chat доказал важную вещь: децентрализация возможна на существующей инфраструктуре, и люди готовы этим пользоваться. Аудитория проекта — миллионы. Это не нишевый эксперимент, а рабочий продукт. Но ограничения email как транспорта никуда не делись. CSMP пытается пойти дальше: спроектировать транспорт, где email — лишь один из возможных каналов, а идентификатор пользователя не привязан к почтовому ящику. Получится ли так же просто, как Delta Chat? Время покажет.

Почему CSMP не использует блокчейн

У читателя, знакомого с децентрализованными системами, на этом месте может возникнуть закономерный вопрос: «А где блокчейн? Как вы достигаете консенсуса? На каком токене это всё работает?»

Ответ: нигде, никак и ни на каком.

Проблема блокчейна в коммуникациях

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

Однако для мессенджера или платформы публикаций эта задача избыточна и вредна по трём причинам.

Причина 1: Приватность

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

Для журналиста, общающегося с источником, или чиновника, обсуждающего рабочие вопросы, такая «прозрачность» метаданных — катастрофа. CSMP намеренно не хранит историю транзакций. DHT-записи имеют TTL и «протухают», а факт доставки сообщения известен только участникам переписки.

Причина 2: Скорость и стоимость

Каждая запись в блокчейн стоит денег (газ) и требует времени на подтверждение блока (от долей секунды до минут). Мессенджер, в котором отправка «Привет, как дела?» стоит $0.05 и занимает 15 секунд, обречён.

CSMP использует криптографию, но не консенсус. Подпись контейнера проверяется локально на устройстве получателя за миллисекунды и не требует ни платы, ни ожидания майнеров.

Причина 3: Масштабируемость

Глобальный блокчейн хранит всю историю всех транзакций на каждом полном узле. Если бы Telegram работал на блокчейне, объём хранилища каждого узла уже исчислялся бы петабайтами, а синхронизация нового клиента занимала бы недели.

CSMP разделяет данные: лёгкие Message Capsule живут недолго и удаляются, а тяжёлые Article Capsule и Media Block реплицируются только теми, кто в них заинтересован. Сеть не обязана помнить всё.

Риски: что может пойти не так

Холодный старт

Сеть без пользователей — мёртвая сеть. DHT-таблица пустая, Депо не отвечают, искать контент негде. Никто не придёт в мессенджер, где никого нет. Signal, Matrix, Mastodon — все бились об эту стену годами.

Что можно сделать. Во-первых, мосты в существующие сети. Клиент CSMP на старте прикидывается обычным Matrix-клиентом или почтовиком, а параллельно потихоньку обрастает CSMP-совместимыми данными. Во-вторых, SDK для тех, у кого уже есть аудитория: банки, госуслуги, CRM. Пользователь получает верифицированные уведомления и даже не знает, что под капотом CSMP. В-третьих, ранним операторам нод нужен стимул — репутация, скидки на хостинг, что угодно, лишь бы подняли и держали.

UX управления ключами

«Сохраните сид-фразу из 12 слов. Потеряете — всё пропало». Девяносто девять процентов обычных пользователей закрывают вкладку на этом месте. Telegram и WhatsApp выиграли, потому что там идентификатор — номер телефона, а восстановление — СМС.

Решение — не заставлять пользователя вообще знать о ключах. Социальное восстановление: назначаешь трёх-пятерых доверенных контактов, их клиенты хранят зашифрованные куски твоего ключа. Потерял доступ — попросил друзей подтвердить, и всё вернулось. Аппаратные ключи и Passkeys: Touch ID, Face ID, YubiKey. Приватный ключ живёт в защищённом анклаве устройства и синхронизируется через iCloud или Google. Для корпоратов — делегирование: пусть IT-отдел разбирается с ключами, как сейчас разбирается с сертификатами ЭЦП.

Модерация без цензора

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

Модель «почтового отделения» снимает часть риска. Оператор хранит запечатанные контейнеры и технически не может заглянуть внутрь. Юридически — как посылка на почте. Ответственность на отправителе и получателе. Дальше — динамическая федерация. Парковка А говорит: «Всё, с Парковкой Б я больше не работаю, там бардак». Клиенты Парковки А перестают видеть контент с Б. Репутация начинает стоить денег. И третий слой — клиентские фильтры. Роскомнадзор или кто угодно публикует список хешей запрещёнки. Клиент может сверяться с этим списком и не показывать такой контент. Фильтрация на клиенте, не на сети.

Бессрочное хранение никто не гарантирует

В децентрализованной сети никто не обязан хранить данные вечно. Владелец Депо выключил сервер — статья исчезла. А ведь одно из главных обещаний CSMP — долговечность и верифицируемость публикаций.

Решение — экономика и зеркалирование. Filecoin-подобная модель: автор прикрепляет к Article Capsule небольшой платёж, узлы получают долю за гарантированное хранение. Национальные архивы и библиотеки могут держать Архивные Ноды и зеркалировать весь публичный контент в своей юрисдикции. Для социально значимого — самое то. Ну и коллективное резервирование: включил режим «Архивариус» — твой клиент стал пиром для всех статей, которые ты читаешь. Чем популярнее публикация, тем больше копий в сети.

Батарейка сядет

DHT, проверка подписей, репликация контейнеров — телефон нагрелся и выключился к обеду. Никто не будет жертвовать батареей ради идеи.

Мобильный клиент должен быть лёгким. Не участвует в DHT, не реплицирует чужие данные. Только отправляет и получает своё через Парковку. Вся тяжёлая работа — на стационарных узлах. Проверка подписей и загрузка медиа — только по Wi-Fi и на зарядке. Уведомления — через стандартные APNS или FCM, а не постоянным опросом Парковки. Протокол должен быть невидимым для устройства.

Заключение: экономика и сложность

Самое важное что нужно решить, это уменьшить у архитектуры порог входа. Пользователю (или администратору) нужно осознанно выбирать «Парковку» или поднимать свою ноду (что, впрочем, уже реально на Raspberry Pi за 15 минут с использованием контейнеризации Docker). Это требует чуть большей цифровой гигиены, чем регистрация по номеру телефона. Пока идеального решения я не нашел.

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

P.S. Пока протокол на уровне идеи, которая требует доработки и проверки в деле. Ноду начал разрабатывать и как только, что-то получится обязательно с вами поделюсь.

Благодарю @Aleksandr_Sv за подсказку про Delta Chat

Репозиторий протокола — https://github.com/dev993848/csm-protocol