Мессенджер с признаками параноидального расстройства

Начиная программировать, пишем «Hello world». Потом файлики на диске, простая база данных, сокеты, сеть, запрос-ответ. Апогеем становится желание написать чат. Клиент-серверная классика! Но классика проста только при объяснении общей схемы, а на деле идеального мессенджера человечество так и не получило.

Моё параноидальное расстройство (о котором я узнал совсем недавно) ещё в ~2019 году отчётливо давало понять, что не существует ни одного мессенджера, которым было бы удобно пользоваться без постоянного риска для приватности и построения социального графа. Увлечение скрытыми сетями (I2P, Tor и другими) только усиливало это ощущение, засасывая меня в пропасть, откуда даже святая святых HTTPS кажется изобретением Старшего брата, а анонимность в сети — наивным пубертатным мифом. Домашний провайдер видит доменное имя, к которому вы обращаетесь, так как оно передаётся в открытом виде до установления защищённого соединения. По частоте и размеру передаваемых данных можно понять наверняка, что именно вы делаете онлайн (пишете, листаете ленту, смотрите видео, звоните и т. п.). Другими словами, эпицентр жизни всей современной цивилизации прозрачный до неприличия. И количество наблюдателей в этом хаосе не детерминировано, как количество слушателей радиостанции. А что про мессенджеры?

Популярные мессенджеры грешат централизованностью. Их задача — запереть пользователя внутри инфраструктуры, чтобы продавать свою рекламу (и, может быть, для чего-то ещё). Не буду перечислять популярные мессенджеры — все они авторизуют пользователя по номеру телефона. Что такое номер телефона? Это паспорт абонента, а также возможность определить его точное местонахождение через триангуляцию (по сотовым вышкам). Парочка более-менее вменяемых мессенджеров могут не требовать номер телефона, оставляя возможность регистрации по email или как-то ещё. Но ключевая беда централизации не в способе регистрации, а в единой точке обработки всего трафика. Даже если взять в пример решение с честным сквозным шифрованием, которое скрывает содержимое переписки от сервиса, незащищённой остаётся самое ценное — метаинформация, которая сообщает, кто с кем и как часто общается, сохраняя сведения о мобильных и десктопных устройствах, с которых абоненты выходят в сеть. Социальный граф позволяет определить интересы пользователя, его окружение, близость с отдельно взятыми абонентами, а информация об устройстве и сети — уточнить этот рисунок по социальному принципу (дорогое или дешёвое устройство) и местонахождение (как минимум с точностью до страны). Автоматизированный сбор и анализ больших данных давно не экзотика, когда по миру шагают ИИ-системы и компании в духе Palantir. Для чего это кому-то нужно? Не знаю, но мне не нравится само допущение. Нормализация такого профилирования изрядно напрягает, особенно когда даже легендарный Сноуден упоминает Signal как один из лучших мессенджеров на свете. Signal — это централизованный сервис с конкретным юрлицом, офисом и точкой контроля. Может быть, Сноуден всего лишь промоутер этой конторы, кто его знает. История помнит примеры пиара устройств для безопасной передачи данных, цель которых не в реальной безопасности, а в возможности читать доверчивых врагов и конкурентов (речь про Crypto AG).

Проблему единой точки отказа давно решают децентрализация и открытые протоколы. Самый простой пример — электронная почта. Огромное количество серверов общаются между собой, позволяя людям быть на связи без единого хозяина сверху. Среди мессенджеров в разной степени популярность завоевали протоколы XMPP и Matrix, а также DeltaChat, который работает поверх того самого email (ну почти). В рамках конкретного протокола легко поднять свой независимый сервер для общения с остальным миром. Однако, во всех названных решениях остаётся неприятный нюанс — сервер, который даже при активном оконечном шифровании переписки видит метаинформацию. Если сервер свой, это не страшно. Но не забывайте, что ваш собеседник может пользоваться другим сервером, и контроль над ним — это снова слепое пятно доверия.

Если сервер — проблема, почему бы от него не отказаться? Такая мысль живёт давно и имеет практические воплощения. Существуют бессерверные мессенджеры вроде Tox, но их изъян в том, что оба собеседника должны быть одновременно в сети, чтобы сообщение было доставлено. Также у подобных решений проблемы с поддержкой нескольких устройств на одном аккаунте, что для современного пользователя весьма ощутимый дискомфорт.

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

Планка современного мессенджера задрана очень высоко. Мы привыкли к звонкам через них. А что такое звонок (особенно с видео)? Это соединение между абонентами, главный критерий которого — наименьшая задержка. Чаще всего для этого используют протокол WebRTC, который в прямом смысле стремится установить соединение между участниками без посредников посередине. Он поддерживается даже веб-браузерами и позволяет участвовать в видеоконференциях без отдельного приложения. Издержки? Прямая утечка вашего IP-адреса собеседнику на другом конце. Нередко WebRTC течёт мимо настроек прокси браузера и даже мимо системного VPN из-за особенностей работы с UDP и маршрутизацией.

Мессенджер Session, который работает через анонимную сеть Tor, на момент написания статьи предоставляет прямые звонки через обычный интернет. То есть кнопочка звонка в супер-анонимном мессенджере внезапно пытается отдать собеседнику ваш IP-адрес! Ну не совсем внезапно, конечно. Об этом нюансе в мессенджере предусмотрено явное предупреждение. Загвоздка в сети Tor. Она позволяет только TCP-соединения, которые плохо подходят для звонков из-за контроля целостности и увеличенной длины маршрута. Вместо костылей и чуть более заметных задержек при разговоре разработчики пошли в сторону прямого WebRTC. По апокрифу Гёте, для таких людей в аду есть отдельный периметр.

SimpleX не хвастается изкоробочной поддержкой анонимности на уровне сети и работает через несколько серверов сообщества в обычном интернете, что для внешнего наблюдателя делает блокировку протокола простейшей задачей. Звонки также на WebRTC, но по умолчанию используют промежуточный сервер для сокрытия реального IP-адреса собеседника. Можно поднимать свои серверы, но заморачиваться этим будут единицы, поэтому в сухом остатке имеем несколько серверов в руках горстки человек и на паре провайдеров, которые создают условно единую точку для сбора метаданных об активности среди пользователей SimpleX (и это касается не только звонков).

Как эпитафию данным и некоторым другим интересным решениям, надо сказать, что на территории РФ всё это не работает (почти). Горстка публичных серверов в клирнете и узнаваемые сигнатуры — уязвимая цель для введения ограничений.

Полюбившиеся бизнесу XMPP и Matrix, которые не заблокированы на уровне протокола и имеют понятное федеративное устройство (ставь сервер и сиди на нём с друзьями), используют открытую маршрутизацию вида user@server, где по имени сервера можно определить место базирования аккаунта. То есть более чем корпоративным решением эти мессенджеры назвать нельзя: приватность под большим вопросом, а анонимность на уровне протокола исключена как явление.

За несколько лет я всерьёз пробовал пользоваться всем, что описал, и некоторыми другими мессенджерами на полтора землекопа, но во всех нашёл упомянутые или схожие проблемы и неудобства.

Как быть?

Делай сам!

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

Моя первая попытка изобрести мессенджер мечты была в 2020. Провалилась с треском через несколько недель. Описание протокола превратилось в сырой черновик, который упирается в те же узкие места, что и уже работающие опенсорсные федеративные протоколы. Позже стало ясно, что протокол и даже его реализация — огромная и тяжёлая, но далеко не единственная часть пути. Клиентское приложение — зачастую недооценённый по сложности компонент, который требует огромной компетенции в области UI/UX.

Как бы путь ни был сложен, начать надо с требований к результату.

Отправная точка

Удобства:

1. Регистрация без привязки к внешним идентификаторам;

2. Личные сообщения и звонки;

3. Групповые беседы;

4. Боты и автоматизация (мессенджер как фронтэнд стороннего сервиса);

5. Передача файлов;

6. Поддержка нескольких устройств на аккаунте;

7. Возможность менять сервер без смены идентификатора (бесшовный переезд);

8. Офлайн сообщения (не нужно быть на связи одновременно с отправителем);

9. Удобное добавление в контакты.

Нужно исключить чего бы это не стоило:

1. Деанонимизацию на уровне сети (никаких прямых соединений между пользователями);

2. Определение сервера собеседника, даже если оба пользователя сидят на одном;

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

4. Простую привязку сетевой активности пользователя к протоколу.

Фичи безопасности:

1. Гибридные пост-квантовые шифрование и подпись;

2. Оконечное шифрование без открытых метаданных;

3. Возможность физически разнести точку входа пользователей и ядро сервера;

4. Примитивный протокол на стороне сервера, сервер как транспорт. Всё разнообразие на уровне конечного приложения.

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

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

Если вы ненавистник нейрослопа, генеративного ИИ и сами лучше всех, предлагаю почитать критику Линуса на эту тему и попробовать самим решить поставленные выше задачи с бюджетом в 500$ (или даже пусть x100). Для справки: этот текст написан без использования ИИ.