В прошлые разы я разбирал, как мы встроили обход блокировок прямо в iOS-приложение: sing-box внутри бинарника, VLESS + Reality, relay как расходник, конфиг отдельно от сборки. Та статья закрывала ровно одну задачу: довести трафик мессенджера до сервера там, где прямое соединение режется.

Но в самом конце был честный абзац, который мне не давал покоя. Я написал тогда: туннель меняет то, как соединение выглядит для цензора по дороге, и не меняет того, кто стоит на концах. Оператор relay (в нашем случае мы сами) видит ваш трафик ровно так же, как его видел бы провайдер при прямом подключении.

Вот про эту дыру и будет текст. Она называется красиво: метаданные. На практике это означает, что один relay видит больше, чем должен. И мы её закрыли, не трогая боевой парк relay вообще. Без маркетинга, по делу.

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

Полюс первый: чистый P2P. Никаких серверов, клиенты говорят напрямую. Звучит красиво ровно до первого практического вопроса. Собеседник офлайн, а вы хотите написать ему сейчас. Куда уйдёт сообщение? В никуда, ждите, пока он включит телефон одновременно с вами. NAT, симметричные файрволы, спящий Android, который убивает фоновые сокеты. P2P горит на неудобстве.

Полюс второй: сервер. Удобно, офлайн-доставка есть, пуши есть. И ровно одна коробка, в которой лежат личности всех, граф контактов всех, очереди всех. Эту коробку можно заблокировать по сети, можно изъять физически, можно прийти к оператору с предписанием. Серверные мессенджеры горят на сервере.

Один из наших пользователей в бете сформулировал это лучше, чем мы в любой презентации: обсуждение альтернатив всегда имело два полюса. Либо ищем инфраструктуру как в Matrix, где все сидят по своим загонам и не пишут друг другу. Либо сидим без офлайн-сообщений как в P2P. Либо вообще не можем подключиться, потому что мосты для обхода блокировок съела моль.

Мы делаем RCQ, мессенджер в духе старой аськи, но на современной крипте. И последние месяцы мы потратили на то, чтобы найти выход из этого треугольника. Ниже модель, к которой мы пришли, и, что важнее, места, где она пока спотыкается. Это не готовый протокол, это дизайн и первые слои. Но он внутренне непротиворечив, и спор о двух полюсах он закрывает.

Блокировки это одно. Их обходят: VLESS, Reality, прокси, про это уже написано много, в том числе у нас. Но есть сценарий жёстче. Интернета нет вообще. Не «YouTube не открывается», а мобильную сеть увели в ноль, Wi-Fi бесполезен, потому что аплинк перекрыт. Такое включают точечно: митинг, площадь, район, иногда целая страна на несколько часов.

Вопрос простой: могут ли два телефона в этой ситуации всё равно обменяться сообщением. Без вышек, без интернета, без сервера. Ответ: да, но честный ответ длиннее, и в нём много «но». Мы (команда из трёх человек, делаем мессенджер RCQ) собрали для этого режим, который называется Radio. Ниже что он реально умеет, чего не умеет, и какие грабли мы собрали по дороге.

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

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

1. Фундамент: сервер, который мало что знает

Сначала коротко про основание, иначе дальше будет непонятно.

- Идентификатор это UIN, просто число. Никакого номера телефона, никакой загрузки списка контактов. Аккаунт не привязан к личности, его можно сжечь и завести новый за секунды.

- Sealed sender: отправитель запечатан внутри зашифрованного конверта, а не лежит в заголовке. На транспортном уровне сервер видит "кому доставить", но не "от кого". Кто это понимает, тот сразу видит, что граф общения на сервере не собирается.

- Контент шифруется end-to-end: эфемерный X25519 на сообщение, HKDF, ChaCha20-Poly1305. Сервер пересылает шифротекст, ключей у него нет.

Идея простая: сервер это в основном тупая труба для шифротекста. Нет телефонов, нет графа, нет содержимого. Это важно для всего дальнейшего.

2. Острова: свой сервер вместо нашего

Раз сервер это тупая труба, его можно вынести куда угодно. Любая организация (редакция, юрфирма, команда, НКО) поднимает свой экземпляр RCQ, свой остров, и общается внутри него: свой сервер, свои UIN, своя история, свои группы, отдельно от публичной сети.

В прошлой статье я рассказывал, как мы встроили VLESS + Reality прямо в наше iOS-приложение через sing-box, чтобы обход блокировок был не задачей пользователя, а деталью реализации. Если коротко: TLS-рукопожатие проксируется на посторонний крупный сайт, активный пробинг упирается в этот сайт, IP относимся как к расходнику, конфиг доставляется отдельно от сборки. Подход работает, и для подавляющего большинства соединений из России работает прямо сейчас.

Кроме одного класса сетей, в которых не работал.

Внутри этого класса оказались, в том числе, корпоративные подсети, гостевой Wi-Fi в некоторых аэропортах и часть регионального покрытия одного из операторов. Картина в логах одна и та же. Туннель поднимается, TCP-соединение на relay открывается, TLS-рукопожатие начинается, и через секунду sing-box на сервере пишет в журнал: REALITY: processed invalid connection. Сразу обрыв, нет ретраев которые что-то меняют.

Эта статья про то, что мы увидели в этих сетях, почему Reality в одиночку их не пробивает, и что мы поставили рядом, чтобы пробивал. Если читали предыдущую часть, продолжайте отсюда. Если не читали, важен один тезис: туннель у нас живёт внутри приложения, через sing-box, скомпилированный в нативный фреймворк, без системного VPN.

Мы делаем мессенджер. Весной 2026 наш бэкенд начал отваливаться у части пользователей из России: HTTPS‑запросы к API таймаутятся, WebSocket не поднимается. Картина знакомая всем, кто держит сервис с одним доменом и одним IP.

Для мессенджера это приговор. Не «неудобно», а именно приговор: приложение, которое не может даже подключиться, бесполезно. И вариант «попросите пользователя сначала включить VPN» нас не устраивал совсем. Ниже разберу, почему мы в итоге встроили обход прямо в приложение, на чём он работает и на какие грабли мы наступили. Без маркетинга, по делу.