Когда делаешь приватный мессенджер, рано или поздно упираешься в неудобный вопрос: что именно защищает пользователя, ваши обещания или ваша архитектура. Обещания не проверить снаружи. Поэтому в RCQ мы старались, чтобы приватность держалась на устройстве и на структуре данных, а не на том, что мы хорошие ребята.
В этой статье разберём две вещи, которые из этого выросли: острова (свой сервер) и мультиличность (несколько независимых зашифрованных аккаунтов на одном телефоне). И отдельно, без прикрас, расскажем, где у этого подхода границы.
1. Фундамент: сервер, который мало что знает
Сначала коротко про основание, иначе дальше будет непонятно.
Идентификатор это UIN, просто число. Никакого номера телефона, никакой загрузки списка контактов. Аккаунт не привязан к личности, его можно сжечь и завести новый за секунды.
Sealed sender: отправитель запечатан внутри зашифрованного конверта, а не лежит в заголовке. На транспортном уровне сервер видит "кому доставить", но не "от кого". Кто это понимает, тот сразу видит, что граф общения на сервере не собирается.
Контент шифруется end-to-end: эфемерный X25519 на сообщение, HKDF, ChaCha20-Poly1305. Сервер пересылает шифротекст, ключей у него нет.
Идея простая: сервер это в основном тупая труба для шифротекста. Нет телефонов, нет графа, нет содержимого. Это важно для всего дальнейшего.
2. Острова: свой сервер вместо нашего
Раз сервер это тупая труба, его можно вынести куда угодно. Любая организация (редакция, юрфирма, команда, НКО) поднимает свой экземпляр RCQ, свой остров, и общается внутри него: свой сервер, свои UIN, своя история, свои группы, отдельно от публичной сети.
Что это даёт на практике:
Нет одной большой мишени. Публичная сеть это единая точка интереса. Сто отдельных островов это сто отдельных целей, и компрометация одного не трогает остальные.
Метаданные (то немногое, что вообще есть) остаются у владельца острова, а не у нас.
Снимается вопрос "а если на вас надавят". Если сервер ваш, давить надо на вас, а не на нас, и вы сами решаете, что на нём хранится. А хранить, напомню, почти нечего.
Технически клиент не прибит к нашему домену: адрес сервера это параметр. Подключиться к острову можно прямо при регистрации или добавить аккаунт на нём позже. Что подводит ко второй части.
3. Мультиличность: несколько вас на одном телефоне
Задача звучала так: дать на одном устройстве набор полностью независимых личностей. Не темы оформления, а разные аккаунты: у каждого свой сервер, свой UIN, свои ключи, свои контакты и своя история. Рабочая на корпоративном острове, личная на публичной сети, ещё одна под что-то третье. И переключение между ними мгновенное, без перелогинов и без перезапуска приложения.
Главная сложность тут не в UI, а в том, чтобы личности реально не протекали друг в друга. Сделаешь спустя рукава, и данные одной всплывут в другой, и вся затея бессмысленна. Поэтому изоляция идёт до самого низа, и ключ всего этого это локальный UUID аккаунта:
Реестр аккаунтов хранит только метаданные маршрутизации: этот UUID, адрес сервера, метку. Секретов в нём нет.
Секреты каждого аккаунта (UIN, токен, приватные ключи) лежат в зашифрованном хранилище под префиксом его UUID. Файл физически один, но слоты не пересекаются.
База сообщений у каждого аккаунта своя, отдельным файлом с UUID в имени. Треды не смешиваются на уровне файловой системы.
Избранное, архив, счётчики непрочитанного тоже разложены по этому префиксу.
Переключение это горячая пересборка: рвём текущее соединение, перенаводим все хранилища на UUID другого аккаунта, перечитываем его базу, поднимаем сокет заново. Снаружи это выглядит как мгновенная смена личности, внутри это аккуратная замена того, на какие данные смотрит работающий процесс.
Отдельная возня была с апгрейдом старых установок. У кого уже был один аккаунт со старой схемой (без префиксов), он при первом запуске молча оборачивается в первый аккаунт реестра: генерим UUID, переносим под него ключи, переименовываем файл базы. Со стороны пользователя не происходит ничего, и это правильно, апгрейд не должен ничего ронять.
4. Честно: от чего это НЕ спасает
Эту часть обычно стыдливо пропускают. Мы считаем, что без неё текст про безопасность это враньё, поэтому она тут.
Это не спасает от заражённого устройства. Если на телефон прилетел Pegasus или похожий имплант уровня ядра, он читает всё уже после расшифровки, прямо с экрана и из памяти. От этого не защищает ни один мессенджер, ни Signal, ни мы. End-to-end защищает данные от сети и сервера, но не от того, кто уже владеет вашим телефоном. Любой, кто обещает иммунитет к Pegasus, говорит неправду.
Forward secrecy у нас разъехалась по платформам, и это надо сказать прямо. На iOS установленные сессии идут по Double Ratchet, то есть полноценный forward secrecy уже есть. На Android сейчас более простая схема v=1 без forward secrecy: при утечке долговременного ключа прошлая переписка к нему раскрывается. Перенос Double Ratchet на Android это наша ближайшая криптографическая задача.
Независимого аудита пока нет. Примитивы стандартные и проверенные, но "мы написали аккуратно" это не то же самое, что "это проверили снаружи". Аудит в планах, ищем под него финансирование. До него мы не говорим "доказано безопасно", и вам не советуем верить тем, кто говорит.
Приватный мессенджер, который не проговаривает свои границы, опаснее честного: он создаёт ложное чувство защищённости.
Где это всё лежит
Острова и мультиличность уже работают, это та часть, которую мы довели. Forward secrecy на Android и сверка отпечатков ключей (чтобы закрыть подмену ключа на стороне сервера) в ближайших планах, аудит дальше.
Код клиентов открыт, ссылки под статьёй. Если вы из тех, кто перед тем как доверять смотрит в исходники, мы только за.
Ссылки (всё под AGPL-3.0):
iOS-клиент: https://github.com/rcq-messenger/rcq-ios
Android-клиент: https://github.com/rcq-messenger/rcq-android
Референс сервера: https://github.com/rcq-messenger/rcq-server-ref
Спецификация протокола: https://github.com/rcq-messenger/rcq-spec
Комментарии (8)
ma1uta
31.05.2026 01:17Почему решили делать своё решение? И в чём ваш протокол лучше чем matrix и xmpp?
И вопросы:
где s2s спецификация?
не увидел поддержки нескольких устройств, она есть?
почему сделали свою аутентификацию, а не взяли OIDC?
не увидел ролевой модели в чатах (админ/модератор/пользователь), она присутствует?
почему в спеке поддержка только одного эфемерного ключа, а не нескольких?
rcq Автор
31.05.2026 01:17Своё не из любви к велосипедам. Matrix и XMPP про федерацию и совместимость, а нам важнее минимум метаданных и анонимность. У них сервер видит состав комнат, граф, presence. У нас sealed sender, сервер не знает даже от кого сообщение. За это и платим отсутствием федерации. Кстати это сразу ответ про s2s: её нет специально, острова это изолированные инстансы, а федерация и есть лишний канал утечки метаданных.
Мультидевайса пока нет, врать не буду. Мультиаккаунт есть (несколько личностей на телефоне), но это другое. На libsignal он ложится естественно, доберёмся.
OIDC не подходит по смыслу: это провайдер, который знает кто ты и когда зашёл. А аккаунт у нас анонимный, без почты и телефона. Регистрация выдаёт UIN и токен под ключ, сгенерированный на устройстве, пароля нет вообще.
Роли пока примитивные: владелец и участники, вся модерация на владельце (кик, закреп, кто может постить, закрыть группу). Полноценных админов и модераторов нет, хотим добавить.
Про эфемерный ключ: вы смотрели v=1, это запасной режим (ECIES) для случая, когда у собеседника ещё нет libsignal-бандла. Боевой путь v=2, там полноценный libsignal: X3DH/PQXDH плюс Double Ratchet, ключей хватает и forward secrecy на месте.
ma1uta
31.05.2026 01:17То есть переустановка - это потеря аккаунта, доступ к нему больше не вернуть, только создавать новый?
Как искать других пользователей?
И утеря аккаунта - утеря истории?
Как подтверждать пользователей, то есть подтвердить, что за данным UIN-ов нужный человек (например, чтобы его добавить в закрытую группу)?
Как бороться с ботами и спамом, когда в открытую группу заходит кто угодно и может постить что угодно (включая запрещённую информацию)?
Если нужна максимальная анонимность и полноценный peer-to-peer, то смотрели в сторону Tox и Briar?
rcq Автор
31.05.2026 01:17По порядку.
Переустановка и потеря устройства. Да, аккаунт это ключ, сгенерированный на устройстве, без пароля, почты и телефона. Снёс приложение без бэкапа, ключ пропал, UIN не вернуть: на сервере нет ни пароля, ни почты, чтобы что-то сбросить. Это осознанная цена анонимности, по смыслу как seed-фраза у криптокошелька. Сейчас восстановления нет, шифрованный экспорт ключа и истории в планах.
Поиск людей. По UIN или QR, обмен происходит вне сервиса, как в ICQ. Плюс есть «Люди рядом» (геохеш, без точных координат), случайный чат и поиск групп.
История. Лежит локально и шифрованно, сервер сообщения после доставки удаляет, да он их и прочитать не может. Поэтому потеря аккаунта это потеря истории, серверу просто нечего отдать. Лечится тем же локальным шифрованным бэкапом, что и ключ.
Подтвердить, что за UIN нужный человек. Через safety numbers, это отпечаток ключей как в Signal: сверили число лично или по другому каналу, значит за UIN тот, кого вы ждёте. Плюс приложение предупреждает, если ключ контакта сменился. В закрытую группу владелец добавляет по UIN, а доверие к этому UIN вы проверяете отпечатком.
Боты, спам, запрещёнка в открытых группах. Тут честно: сервер контента не видит (sealed sender плюс e2e), поэтому серверной модерации по содержимому быть не может в принципе. Что есть на деле: модерация на владельце (кик, кто может постить, режим «пишет только владелец», закрыть группу), репорты с баном UIN, антифлуд-лимиты. И свежее: регистрацию на сервере-острове теперь можно закрыть инвайтами, тогда заходит не кто угодно, а по приглашению. Полноценные роли модераторов ещё дорабатываем. Если остров публичный и открытый, модерация это зона его владельца, у self-host тем более их собственная.
Tox и Briar. Смотрели, по духу они нам ближе всего. Briar это Tor плюс p2p, метадата-стойкость отличная, но цена высокая: нужен Tor (задержки, батарея), доставка обычно требует, чтобы обе стороны были онлайн, мультидевайса нет, UX тяжёлый. Tox это p2p поверх DHT, а DHT светит ваш IP и presence узлам сети, и с офлайн-доставкой там туго. Мы сознательно выбрали тонкий сервер-релай: он держит очередь из запечатанных блобов, которые сам прочитать не может, зато сообщение дойдёт, когда вы офлайн, и поверх этого живёт обход блокировок. Это просто другая точка на шкале: не федерация (Matrix, XMPP) и не чистый p2p (Tox, Briar), а минимум метаданных с обычным сервером доставки. Для близкого радиуса и офлайна у нас есть локальный mesh по Bluetooth (в том числе и внутри одной локальной сети по WiFi Direct).
ma1uta
31.05.2026 01:17С историей будут проблемы, хранить на мобильном клиенте не получится, она слишком быстро (2-3 года активной переписки) займёт всё свободное место. Нет варианта часть истории скидывать в архив?
Если вы используете тонкий сервер, который можно просто назвать relay-сервером, то как реализована подгрузка медиа-контента, чтобы ip-адреса не утекали? То есть, обычно сервер идёт за картинкой, скачивает и хранит у себя. Клиент никуда кроме сервера не ходит, поэтому он тянет картинку только со своего сервера. Не будет же клиент идти в обход сервера напрямую по адресу картинки, так как это утечка ip-адреса пользователя?
Да и relay-сервера видят ip-адреса пользователей. Можно выбрать relay-сервер, к которому подключаться, чтобы цепляться только к доверенным серверам?
Как сервера друг друга находят? Как работает маршрутизация, если Alice подключилась к relay1, а Bob к relay2, и Alice хочет отправить сообщение Bob-у?
rcq Автор
31.05.2026 01:17История. Тяжёлое это медиа, а оно на телефоне постоянно не лежит: файл это зашифрованный блоб на сервере, клиент тянет по запросу и кэширует, кэш можно чистить. Текст лёгкий даже за годы. Архив старого добавим.
Медиа и IP. Клиент ходит только на свой сервер, не по сторонним URL. Картинка лежит блобом на том же бэкенде и тянется по id. Наружу IP не утекает, свой сервер контент всё равно не видит.
Relay видит IP. Да, любой сервер видит ваш TCP-адрес, без Tor/VPN никак. У нас знание расщеплено: relay видит IP, но не личность и не контент (TLS-туннель), бэкенд видит личность, но IP уже relay. Пул наш, конфиг подписан. Нужен полный контроль над IP, поднимаете свой остров. Выбор relay вручную на радаре.
Яна на relay1, Саша на relay2. Поправлю: такой модели у нас нет специально. Federation и s2s нет, острова изолированы, Яна и Саша общаются только на одном острове. Relay это не роутер между серверами, а дверь обхода блокировок перед одним бэкендом. Какую дверь ни выбери, попадёшь на тот же сервер.
debagger
Забыли добавить?
rcq Автор
Спасибо, исправили.
Ссылки действительно потерялись при публикации, добавил в конец статьи.
Вот они:
iOS: github.com/rcq-messenger/rcq-ios
Android: github.com/rcq-messenger/rcq-android
Референс сервера: github.com/rcq-messenger/rcq-server-ref
Всё под AGPL-3.0.