Про IP вы правы, и в статье это прямым текстом: IP горят одинаково, relay у нас расходник, вся ставка на быструю ротацию адресов. Reality никогда и не обещал спасти IP, он про другое.
Про протокол XOR и Reality не равны. XOR-обфускация держится ровно до тех пор, пока цензор не смотрит активно. Как только он включает активный пробинг (сам стучится на ваш сервер) или ставит DPI по сигнатуре, XOR и классические VPN-протоколы палятся, и режут не один ваш IP, а весь класс трафика разом, по сигнатуре. Именно так в РФ и Иране массово выпиливают OpenVPN, WireGuard, IKEv2 и простые обфускаторы. Reality на пробинг отвечает чужим легитимным сайтом, сигнатуры протокола нет.
Отсюда вся разница, и она не в красоте, а в цене для цензора. XOR умирает от одного обновления сигнатуры сразу на всех серверах. Reality заставляет банить по одному IP, по мере обнаружения, вручную и дорого. «И там и там в итоге IP-бан» верно по форме, но скорость и стоимость отличаются на порядок. В этом весь смысл, а не в трюкачестве.
И да, конкретно эта статья вообще не про обход, она про метаданные: чтобы один relay по дороге не видел ваш IP и адрес назначения сразу. Одиночный XOR-VPN эту задачу не решает в принципе, там ваш единственный сервер видит всё.
Про слои согласен, плотно. Суть в одной фразе: два relay вместо одного, вход залипает, выход крутится, и если что-то падает, всё откатывается на однохоп. Остальное детали.
Про сбои и нагрузку отвечу конкретно.
Сбои. Однохоп это пол. Умер выход, urltest перевыбирает живую выходную цепочку. Умер вход (подтверждённая блокировка, около минуты), клиент ротирует вход и пересобирает транспорт. Живых relay в пуле меньше двух или онион выключен, клиент сам падает на однохоп, тот самый, что работал и до онион. Худший случай по связности это не «всё легло», а «онион выключился, работаем как раньше». Обрыв входа посреди сессии рвёт всю цепочку (выход идёт внутри входа), клиент переподключается, это секунды переустановки, не потеря данных.
Нагрузка. Онион удваивает стоимость на активную цепочку: вход несёт внутри себя весь выходной туннель, и Reality с vision считаются на двух хопах вместо одного. Для мессенджера ок, трафик маленький и это в основном простаивающий WebSocket плюс короткие сообщения. Для видео я бы по умолчанию не включал. Стационарная добавка к задержке это один лишний хоп RTT, а +0.7s из статьи это разовая установка соединения, не на каждый пакет.
Мир меняется и мы тоже. Думаете такое бы нейронка не сказала в ответ на ваш комментарий? Или мы ответили не по делу, что пуши тут вообще никак не связаны со статьей и сутью проекта?
Спасибо, вопросы правильные, и большинство из них честнее считать не решёнными, а постоянной борьбой. По пунктам.
Магазины и верификация -согласен, и именно поэтому мы на магазины не опираемся. На Android основная раздача это прямой APK с сайта плюс встроенный апдейтер, не Play. Верификация разработчиков ужесточается, да, но прямую установку и открытый код пережить отзыв из стора проще, чем приложению, которое живёт только в магазине. iOS тут реально слабое место: Apple контролирует раздачу целиком и по жалобе выпилит, крыть нечем. Единственное смягчение, iOS-клиент открыт (AGPL, на GitHub), его можно собрать и поставить мимо App Store, плюс в ЕС появились альтернативные сторы. Идеально это не закрывает (появится нужда - откатимся к эре Jailbreak'а, почему нет?).
Блокировки и запрет -тут работает сама архитектура, а не один обходной костыль. Смысл в том, что инфраструктура размазана по пользователям. Остров это просто почтовый ящик, его поднимает кто угодно у себя, и данные не лежат в одной точке, которую можно изъять. Транспорт это релеи, и их задумано много -дешёвые, одноразовые, поднимаемые самими пользователями, "сегодня здесь, завтра там", как гидра. Рубишь одну голову, остальные живут, единой точки входа, которую гасят одним махом, нет. Поверх этого идёт onion-маршрутизация через несколько релеев, чтобы ни один из них не видел разом и кто ты, и куда идёшь, и чтобы прятался сам факт обращения к конкретному острову.
Честно про статус -часть уже работает (наши релеи, обфускация, подписанный конфиг с ротацией без обновления приложения, self-host островов), а массовый пользовательский рой релеев и onion это то, к чему мы идём по этапам, не всё уже включено. И есть по-настоящему трудный кусок, не решённый ни у кого -первичный бутстрап, когда заблокировано всё известное (та же проблема, что у Tor с мостами, серебряной пули нет). А если само использование объявят вне закона и начнут смотреть телефоны, это уже не инженерная задача -улики убрать можно (нет телефона, сжигаемые аккаунты, decoy-PIN, приложение не кричит "запрещёнка", итд), но закон софтом не отменить.
Аудитория, проблема Jabber -cамый сильный и самый честный пункт, и он сложнее любой криптографии. XMPP технически имел всё и умер на сетевом эффекте и UX. Мы не делаем ставку "построим, и придут". У нас есть клин, которого у джаббера не было -люди под реальной цензурой, которым обход нужен прямо сейчас, это совсем другое давление к адопшену. И есть небольшая, но настоящая аудитория, под тысячу зарегистрированных, пришедшая именно из-за этого, а не вопреки UX. Урок джаббера учли буквально -одно опрятное приложение, а не двадцать клиентов на выбор, шифрование по умолчанию, а не "настройте OMEMO". Победим ли мы проблему аудитории вообще, честно, открытый вопрос, тут можно лечь как все. Но клин реальный, и первая тяга есть.
Монетизация -само приложение бесплатное, и навсегда. Платят не люди, а организации. Логика тут стандартная для open-source -код открыт, остров можно поднять самому бесплатно, но большинству это не нужно или некогда, и за удобство и инфраструктуру платят охотно. Что конкретно -бизнесу (редакции, юристы, фонды, команды, которым нельзя в Telegram или WhatsApp) готовая закрытая сеть островов в их контуре под ключ, с настройкой и поддержкой, плюс управляемый хостинг "свой остров в один клик" для тех, кто не хочет возиться с VPS. Тем, кому защита реально нужна и кто платить не может (журналисты, активисты), всё бесплатно по заявке. На рекламе и данных не зарабатываем принципиально, это убило бы смысл. Что коммерция и бескомпромиссная приватность не противоположности, уже показал SimpleX, мы той же дорогой -продаём удобство и инфраструктуру, а не пользователя.
Замечание по делу, пуши действительно главная точка централизации, и на iOS вы абсолютно правы -фоновые уведомления это только APNs, ни один сторонний сервер этого не обойдёт, это ограничение ОС, а не приложения. Лоббировать Apple с Google нам не по силам, не будем притворяться.
Пара уточнений по тому, что реально можно. Это не "всё или ничего" -свой остров подключает собственный ключ APNs, и тогда пуш идёт остров -> Apple напрямую, мимо нашего центра, то есть даже пуш не централизован через нас (в self-host это настраивается). На Android мы FCM сегодня вообще не используем, доставка идёт по живому сокету пока приложение работает, а полноценный фоновый будильник пока отложен. Его, кстати, на Android можно сделать без Google, постоянным foreground-сервисом, как у Briar и FOSS-XMPP клиентов, ценой батареи. На iOS без APNs надёжного фона нет, тут крыть нечем.
И главное по сути -централизация пуша ортогональна(!) тому, что мы децентрализуем. Пуш это всего лишь "пинг, проверь ящик". Аккаунт, переписка и ключи лежат на островах, а не у Apple с Google. Отвалится пуш-канал, вы потеряете не сеть и не данные, а только мгновенность уведомления, сообщения дойдут при следующем открытии. Мы защищаемся от того, что центр выключат, как это случилось с ICQ, а не строим идеальную децентрализацию каждого байта. Пуши важная, но решаемая в рабочем порядке деталь, а не сердце системы.
Нет, это другой уровень. Reticulum это сетевой стек -адресация, маршрутизация и шифрование поверх любой среды, хоть LoRa и радио, вообще без интернета. Мессенджеры (LXMF, Sideband) строят уже поверх него. Мы сеть с нуля не делаем -у нас обычный интернет и модель почтовых ящиков. Остров это тупой ящик с очередью, клиент сам кладёт запечатанный конверт в ящик(и) получателя и сам их опрашивает (читайте статью внимательнее, пожалуйста). По духу это ближе к email или Nostr, чем к Reticulum. Общее есть -идентичность это ключ, центрального авторитета нет, всё шифровано. Ближе всего к миру Reticulum у нас офлайн-режим, радиочат по Bluetooth и Wi-Fi Direct без серверов и интернета, но он намного проще и только локальный, не маршрутизируемый стек. Reticulum отличная штука, просто решает другую задачу.
Рады, что зашло. Только держите план Б наготове: это гонка, и «идеально» сегодня вполне может поплыть завтра, когда подтянут правила. Мы поэтому и закладываемся на UDP плюс обфускацию и на ротацию точек, чтобы при первом шевелении можно было переехать без боли. И спасибо, что отписались по результату, такие репорты полезнее любых наших логов.
Согласен, Reticulum отличная штука, и мы её не игнорируем: это действительно полноценный криптографический сетевой стек, транспортно-агностичный, и как mesh он на голову выше нашего Radio. Тут спорить не с чем.
Но мы решаем другую задачу и на другом слое. Reticulum это СЕТЬ: как пакеты находят друг друга через любую среду. RCQ это МЕССЕНДЖЕР как продукт: кроссплатформенный (iOS, Android, веб / в будущем Desktop-версии), libsignal с forward secrecy, sealed sender, пуши, добавление контакта по короткому номеру, встроенный обход блокировок. Центр тяжести у нас не mesh, а «обычный приватный мессенджер для не-гика», а Radio это офлайн-fallback на случай «интернета нет вообще, люди рядом», сознательно минимальный (ноль настройки, без доп-железа).
Если задача это именно транспортно-агностичная сеть планетарного-галактического-вселенного масштаба, Reticulum правильный инструмент, и переизобретать его мы не пытаемся :)
Если задача «чтобы друзья на айфонах переписывались приватно, с пушами, чтобы при блокировках работало, а при отключении сети остался хоть локальный режим», то это другой продукт. Reticulum и его мобильные клиенты пока для тех, кто готов разбираться, мы целимся в тех, кто разбираться не хочет.
В точку, и это близко к тому, как мы сами на это смотрим. Когда рубят глобальный интернет, локалка возвращается мгновенно, причём не у гиков, а у всех, по той же логике, что и с VPN.
У RCQ это два конца одного спектра. Один конец это ровно ваш сценарий «настроил один раз»: сервер RCQ можно поднять локально, хоть на старом ноуте или Raspberry Pi в доме, и соседи цепляются к нему по обычному WiFi, без выхода в интернет вообще. Получается приватный «остров» на дом или район, со всем шифрованием и без связи наружу. Другой конец это Radio, когда даже точки доступа нет: телефоны напрямую, ноль инфраструктуры, ценой радиуса.
А вот «связать это всё в единое децентрализованное, чтобы не играть в хакера» это честно самая сложная часть, и красиво её пока никто не закрыл. Мы скорее даём набор кубиков (локальный сервер плюс direct-радио), чем обещаем один волшебный mesh. Но вектор вы описали верно: спрос на локалки при первом же серьёзном рубильнике вырастет очень быстро.
Справедливо, и да: если человек стоит рядом, проще сказать вслух. Radio не про это. Он про координацию ГРУППЫ без интернета, когда вы не все в одной точке.
Во-первых, радиус это не «несколько метров». Несколько метров это BLE-маячок для обнаружения, а сами сообщения идут по Wi-Fi Direct, до сотни метров в прямой видимости. Это этаж здания, двор, небольшая площадь, вагон. Голосом через толпу или сквозь стены вы туда не докричитесь, а текст в комнату доходит всем разом.
Во-вторых, текст делает то, что голос не умеет: тихо (в толпе не хочется орать чувствительное вслух), сразу всем участникам и со структурой (координаты, ссылка, фото, закреплённый план).
Про USB-C приёмопередатчик с антенной на километры: это ровно тот путь, о котором выше писали с Meshtastic. Отдельная LoRa-железка на sub-GHz реально берёт километры, ценой отдельного устройства, низкого битрейта и текста без медиа. Направление интересное, но это другой продукт: ты носишь с собой донгл. Radio сознательно про обратный размен, ноль доп-железа и настройки, телефон уже в кармане, ценой радиуса. Разные инструменты под разные сценарии.
Про чужака в чате против релея: это разные вещи. Когда человек заходит в комнату, он участник и видит сообщения, зашифрованные под ключ комнаты, так и задумано. Релей это другое: твой телефон тащит чужой трафик людей, с которыми ты не общаешься. Даже если содержимое зашифровано, релей видит метаданные (кто рядом с кем, тайминги, размеры), может придержать или подменить, становится точкой для спама и деанона по соседству. Опасна именно роль промежуточного релея, а не сам факт членства в чате.
Про точку доступа с сервером: по сути это ровно то, что Radio и делает, только без ручной настройки. Wi-Fi Direct группа это и есть телефон-хаб, к которому подключаются остальные, но без поднятия AP, без раздачи своего интернета и возни с SSID, и сразу со встроенным шифрованием и анонимной личностью. Инстинкт верный, мы пришли к той же звезде.
Справедливо, спасибо за ссылку, посмотрели. Meshtastic это как раз тот случай, когда городской mesh реально работает: и тебе отдельная LoRa-железка на sub-GHz, низкий битрейт, протокол изначально под многохоп и дальние дистанции и так далее. Я же в статье про другое: стоковый смартфон без дополнительного железа, только BLE и Wi-Fi Direct, где ОС душит фоновую радиоработу, дальность маленькая, и честный многохоп там почти не живёт. Это разные инструменты под разные задачи. Meshtastic берёт дальность ценой отдельного устройства и пропускной способности (текст, не голос с фото), Radio берёт телефон, который уже в кармане, ценой радиуса в один хоп. Формулировку в статье поправлю, чтобы не вводила в заблуждение :)
Briar мы уважаем, и про список «но» вы правы: у любого честного P2P и mesh куча ограничений, мы про это в статье прямо пишем. Разница в центре тяжести.
Briar максимально децентрализован: сервера нет вообще, онлайн через Tor, синхронизация через общих контактов. Цена этого: по сути только Android (на iOS его нет), нет пушей (нужен запущенный Tor-сервис), контакты добавляются обменом ссылками, а Tor часто режут. В итоге, как вы и говорите, в полевых условиях остаётся директ по BT/WiFi.
RCQ по умолчанию это обычный онлайн-мессенджер с E2E (libsignal, forward secrecy, sealed sender) через серверный релей: iOS, Android и веб, доставка офлайн-сообщений из очереди, пуши на iOS (на Android в работе), контакт по короткому UIN, и встроенный обход блокировок (VLESS/Reality), без Tor. А наш Radio это как раз «briar-режим» на случай, когда интернета нет совсем, и у него ровно те же физические ограничения, что у любого P2P по BT/WiFi, мы это не прячем.
Честный размен: у нас есть сервер, у Briar нет. Мы платим за это доверием к серверу (минимизируем его через sealed sender и E2E), но получаем кроссплатформенность, пуши и поведение нормального мессенджера. Briar платит удобством за отсутствие сервера. Это разные точки на кривой «приватность против юзабилити», а не «лучше или хуже» в вакууме.
История. Тяжёлое это медиа, а оно на телефоне постоянно не лежит: файл это зашифрованный блоб на сервере, клиент тянет по запросу и кэширует, кэш можно чистить. Текст лёгкий даже за годы. Архив старого добавим.
Медиа и IP. Клиент ходит только на свой сервер, не по сторонним URL. Картинка лежит блобом на том же бэкенде и тянется по id. Наружу IP не утекает, свой сервер контент всё равно не видит.
Relay видит IP. Да, любой сервер видит ваш TCP-адрес, без Tor/VPN никак. У нас знание расщеплено: relay видит IP, но не личность и не контент (TLS-туннель), бэкенд видит личность, но IP уже relay. Пул наш, конфиг подписан. Нужен полный контроль над IP, поднимаете свой остров. Выбор relay вручную на радаре.
Яна на relay1, Саша на relay2. Поправлю: такой модели у нас нет специально. Federation и s2s нет, острова изолированы, Яна и Саша общаются только на одном острове. Relay это не роутер между серверами, а дверь обхода блокировок перед одним бэкендом. Какую дверь ни выбери, попадёшь на тот же сервер.
Переустановка и потеря устройства. Да, аккаунт это ключ, сгенерированный на устройстве, без пароля, почты и телефона. Снёс приложение без бэкапа, ключ пропал, 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).
Подход рабочий, но громоздкий: целая VM плюс SSH-туннель плюс per-app routing. Для split-tunnel на 2026-й есть варианты полегче (знаю как минимум несколько):
WireGuard с AllowedIPs. Конфигурируешь WG на хосте, в AllowedIPs указываешь только корпоративные подсети (10.x/8 или какие у вас). Всё что попадает в эти подсети, идёт через WG, остальное напрямую. Не нужна ни VM, ни SOCKS5, ни настройка приложений. Один конфиг :)
Tailscale subnet router. Если корпоративная сеть подключена к Tailscale (или поставлена Tailscale-нода в корп-DMZ как subnet router), на клиенте просто tailscale up, трафик к корпоративным IP идёт через mesh, остальное напрямую. Из коробки, без правки routing-таблиц вручную.
macOS Network Extensions per-app VPN. Если только macOS, нативный API NEAppProxyProvider даёт per-app routing без проксей. Сложнее в реализации, но самое нативное.
Сейчас твой setup решает проблему правильно концептуально, но через три слоя инфраструктуры. WG + AllowedIPs делает то же самое в одном конфиге и гораздо, гораздо эффективнее imho. А так: мое уважение.
Своё не из любви к велосипедам. Matrix и XMPP про федерацию и совместимость, а нам важнее минимум метаданных и анонимность. У них сервер видит состав комнат, граф, presence. У нас sealed sender, сервер не знает даже от кого сообщение. За это и платим отсутствием федерации. Кстати это сразу ответ про s2s: её нет специально, острова это изолированные инстансы, а федерация и есть лишний канал утечки метаданных.
Мультидевайса пока нет, врать не буду. Мультиаккаунт есть (несколько личностей на телефоне), но это другое. На libsignal он ложится естественно, доберёмся.
OIDC не подходит по смыслу: это провайдер, который знает кто ты и когда зашёл. А аккаунт у нас анонимный, без почты и телефона. Регистрация выдаёт UIN и токен под ключ, сгенерированный на устройстве, пароля нет вообще.
Роли пока примитивные: владелец и участники, вся модерация на владельце (кик, закреп, кто может постить, закрыть группу). Полноценных админов и модераторов нет, хотим добавить.
Про эфемерный ключ: вы смотрели v=1, это запасной режим (ECIES) для случая, когда у собеседника ещё нет libsignal-бандла. Боевой путь v=2, там полноценный libsignal: X3DH/PQXDH плюс Double Ratchet, ключей хватает и forward secrecy на месте.
1. Да, согласен, корректнее сравнивать с VeraCrypt hidden volume, где существование скрытого зависит от введённого ключа. Мейнстрим-мессенджеры тут не пример, признаю.
2. Противоречие в нашей модели угроз ты вскрыл честно. Защиту вижу так: decoy опциональный, и тот, кто его настраивает, явно принимает повышенный риск форс-эскалации в обмен на «есть-что-показать». Кто не хочет такого размена, оставляет просто real-аккаунт без decoy/wipe, тогда RCQ выглядит как обычный мессенджер. Не идеальный ответ, но это пользовательский выбор, а не навязанный default.
3. За идею с серверной генерацией + backdating + «дописыванием в момент открытия» спасибо, об этом мы не думали. Подводные, навскидку: (а) server-side генерация создаёт артефакт связи «decoy -> пользователь» на сервере, по запросу властей всплывает; (б) при border-контроле часто airplane mode, server-side fetch не отработает; (в) ровно кластеризованные «свежие» timestamps сами по себе forensic-artifact. Идея жизнеспособна, но требует тонкого балансирования, возьму в копилку.
Спасибо, но тут смешаны два уровня, разведу.
Про IP вы правы, и в статье это прямым текстом: IP горят одинаково, relay у нас расходник, вся ставка на быструю ротацию адресов. Reality никогда и не обещал спасти IP, он про другое.
Про протокол XOR и Reality не равны. XOR-обфускация держится ровно до тех пор, пока цензор не смотрит активно. Как только он включает активный пробинг (сам стучится на ваш сервер) или ставит DPI по сигнатуре, XOR и классические VPN-протоколы палятся, и режут не один ваш IP, а весь класс трафика разом, по сигнатуре. Именно так в РФ и Иране массово выпиливают OpenVPN, WireGuard, IKEv2 и простые обфускаторы. Reality на пробинг отвечает чужим легитимным сайтом, сигнатуры протокола нет.
Отсюда вся разница, и она не в красоте, а в цене для цензора. XOR умирает от одного обновления сигнатуры сразу на всех серверах. Reality заставляет банить по одному IP, по мере обнаружения, вручную и дорого. «И там и там в итоге IP-бан» верно по форме, но скорость и стоимость отличаются на порядок. В этом весь смысл, а не в трюкачестве.
И да, конкретно эта статья вообще не про обход, она про метаданные: чтобы один relay по дороге не видел ваш IP и адрес назначения сразу. Одиночный XOR-VPN эту задачу не решает в принципе, там ваш единственный сервер видит всё.
Про слои согласен, плотно. Суть в одной фразе: два relay вместо одного, вход залипает, выход крутится, и если что-то падает, всё откатывается на однохоп. Остальное детали.
Про сбои и нагрузку отвечу конкретно.
Сбои. Однохоп это пол. Умер выход, urltest перевыбирает живую выходную цепочку. Умер вход (подтверждённая блокировка, около минуты), клиент ротирует вход и пересобирает транспорт. Живых relay в пуле меньше двух или онион выключен, клиент сам падает на однохоп, тот самый, что работал и до онион. Худший случай по связности это не «всё легло», а «онион выключился, работаем как раньше». Обрыв входа посреди сессии рвёт всю цепочку (выход идёт внутри входа), клиент переподключается, это секунды переустановки, не потеря данных.
Нагрузка. Онион удваивает стоимость на активную цепочку: вход несёт внутри себя весь выходной туннель, и Reality с vision считаются на двух хопах вместо одного. Для мессенджера ок, трафик маленький и это в основном простаивающий WebSocket плюс короткие сообщения. Для видео я бы по умолчанию не включал. Стационарная добавка к задержке это один лишний хоп RTT, а +0.7s из статьи это разовая установка соединения, не на каждый пакет.
Мир меняется и мы тоже. Думаете такое бы нейронка не сказала в ответ на ваш комментарий? Или мы ответили не по делу, что пуши тут вообще никак не связаны со статьей и сутью проекта?
Спасибо, вопросы правильные, и большинство из них честнее считать не решёнными, а постоянной борьбой. По пунктам.
Магазины и верификация -согласен, и именно поэтому мы на магазины не опираемся. На Android основная раздача это прямой APK с сайта плюс встроенный апдейтер, не Play. Верификация разработчиков ужесточается, да, но прямую установку и открытый код пережить отзыв из стора проще, чем приложению, которое живёт только в магазине. iOS тут реально слабое место: Apple контролирует раздачу целиком и по жалобе выпилит, крыть нечем. Единственное смягчение, iOS-клиент открыт (AGPL, на GitHub), его можно собрать и поставить мимо App Store, плюс в ЕС появились альтернативные сторы. Идеально это не закрывает (появится нужда - откатимся к эре Jailbreak'а, почему нет?).
Блокировки и запрет -тут работает сама архитектура, а не один обходной костыль. Смысл в том, что инфраструктура размазана по пользователям. Остров это просто почтовый ящик, его поднимает кто угодно у себя, и данные не лежат в одной точке, которую можно изъять. Транспорт это релеи, и их задумано много -дешёвые, одноразовые, поднимаемые самими пользователями, "сегодня здесь, завтра там", как гидра. Рубишь одну голову, остальные живут, единой точки входа, которую гасят одним махом, нет. Поверх этого идёт onion-маршрутизация через несколько релеев, чтобы ни один из них не видел разом и кто ты, и куда идёшь, и чтобы прятался сам факт обращения к конкретному острову.
Честно про статус -часть уже работает (наши релеи, обфускация, подписанный конфиг с ротацией без обновления приложения, self-host островов), а массовый пользовательский рой релеев и onion это то, к чему мы идём по этапам, не всё уже включено. И есть по-настоящему трудный кусок, не решённый ни у кого -первичный бутстрап, когда заблокировано всё известное (та же проблема, что у Tor с мостами, серебряной пули нет). А если само использование объявят вне закона и начнут смотреть телефоны, это уже не инженерная задача -улики убрать можно (нет телефона, сжигаемые аккаунты, decoy-PIN, приложение не кричит "запрещёнка", итд), но закон софтом не отменить.
Аудитория, проблема Jabber -cамый сильный и самый честный пункт, и он сложнее любой криптографии. XMPP технически имел всё и умер на сетевом эффекте и UX. Мы не делаем ставку "построим, и придут". У нас есть клин, которого у джаббера не было -люди под реальной цензурой, которым обход нужен прямо сейчас, это совсем другое давление к адопшену. И есть небольшая, но настоящая аудитория, под тысячу зарегистрированных, пришедшая именно из-за этого, а не вопреки UX. Урок джаббера учли буквально -одно опрятное приложение, а не двадцать клиентов на выбор, шифрование по умолчанию, а не "настройте OMEMO". Победим ли мы проблему аудитории вообще, честно, открытый вопрос, тут можно лечь как все. Но клин реальный, и первая тяга есть.
Монетизация -само приложение бесплатное, и навсегда. Платят не люди, а организации. Логика тут стандартная для open-source -код открыт, остров можно поднять самому бесплатно, но большинству это не нужно или некогда, и за удобство и инфраструктуру платят охотно. Что конкретно -бизнесу (редакции, юристы, фонды, команды, которым нельзя в Telegram или WhatsApp) готовая закрытая сеть островов в их контуре под ключ, с настройкой и поддержкой, плюс управляемый хостинг "свой остров в один клик" для тех, кто не хочет возиться с VPS. Тем, кому защита реально нужна и кто платить не может (журналисты, активисты), всё бесплатно по заявке. На рекламе и данных не зарабатываем принципиально, это убило бы смысл. Что коммерция и бескомпромиссная приватность не противоположности, уже показал SimpleX, мы той же дорогой -продаём удобство и инфраструктуру, а не пользователя.
Замечание по делу, пуши действительно главная точка централизации, и на iOS вы абсолютно правы -фоновые уведомления это только APNs, ни один сторонний сервер этого не обойдёт, это ограничение ОС, а не приложения. Лоббировать Apple с Google нам не по силам, не будем притворяться.
Пара уточнений по тому, что реально можно. Это не "всё или ничего" -свой остров подключает собственный ключ APNs, и тогда пуш идёт остров -> Apple напрямую, мимо нашего центра, то есть даже пуш не централизован через нас (в self-host это настраивается). На Android мы FCM сегодня вообще не используем, доставка идёт по живому сокету пока приложение работает, а полноценный фоновый будильник пока отложен. Его, кстати, на Android можно сделать без Google, постоянным foreground-сервисом, как у Briar и FOSS-XMPP клиентов, ценой батареи. На iOS без APNs надёжного фона нет, тут крыть нечем.
И главное по сути -централизация пуша ортогональна(!) тому, что мы децентрализуем. Пуш это всего лишь "пинг, проверь ящик". Аккаунт, переписка и ключи лежат на островах, а не у Apple с Google. Отвалится пуш-канал, вы потеряете не сеть и не данные, а только мгновенность уведомления, сообщения дойдут при следующем открытии. Мы защищаемся от того, что центр выключат, как это случилось с ICQ, а не строим идеальную децентрализацию каждого байта. Пуши важная, но решаемая в рабочем порядке деталь, а не сердце системы.
Нет, это другой уровень. Reticulum это сетевой стек -адресация, маршрутизация и шифрование поверх любой среды, хоть LoRa и радио, вообще без интернета. Мессенджеры (LXMF, Sideband) строят уже поверх него. Мы сеть с нуля не делаем -у нас обычный интернет и модель почтовых ящиков. Остров это тупой ящик с очередью, клиент сам кладёт запечатанный конверт в ящик(и) получателя и сам их опрашивает (читайте статью внимательнее, пожалуйста). По духу это ближе к email или Nostr, чем к Reticulum. Общее есть -идентичность это ключ, центрального авторитета нет, всё шифровано. Ближе всего к миру Reticulum у нас офлайн-режим, радиочат по Bluetooth и Wi-Fi Direct без серверов и интернета, но он намного проще и только локальный, не маршрутизируемый стек. Reticulum отличная штука, просто решает другую задачу.
Рады, что зашло. Только держите план Б наготове: это гонка, и «идеально» сегодня вполне может поплыть завтра, когда подтянут правила. Мы поэтому и закладываемся на UDP плюс обфускацию и на ротацию точек, чтобы при первом шевелении можно было переехать без боли. И спасибо, что отписались по результату, такие репорты полезнее любых наших логов.
Согласен, Reticulum отличная штука, и мы её не игнорируем: это действительно полноценный криптографический сетевой стек, транспортно-агностичный, и как mesh он на голову выше нашего Radio. Тут спорить не с чем.
Но мы решаем другую задачу и на другом слое. Reticulum это СЕТЬ: как пакеты находят друг друга через любую среду. RCQ это МЕССЕНДЖЕР как продукт: кроссплатформенный (iOS, Android, веб / в будущем Desktop-версии), libsignal с forward secrecy, sealed sender, пуши, добавление контакта по короткому номеру, встроенный обход блокировок. Центр тяжести у нас не mesh, а «обычный приватный мессенджер для не-гика», а Radio это офлайн-fallback на случай «интернета нет вообще, люди рядом», сознательно минимальный (ноль настройки, без доп-железа).
Если задача это именно транспортно-агностичная сеть планетарного-галактического-вселенного масштаба, Reticulum правильный инструмент, и переизобретать его мы не пытаемся :)
Если задача «чтобы друзья на айфонах переписывались приватно, с пушами, чтобы при блокировках работало, а при отключении сети остался хоть локальный режим», то это другой продукт. Reticulum и его мобильные клиенты пока для тех, кто готов разбираться, мы целимся в тех, кто разбираться не хочет.
В точку, и это близко к тому, как мы сами на это смотрим. Когда рубят глобальный интернет, локалка возвращается мгновенно, причём не у гиков, а у всех, по той же логике, что и с VPN.
У RCQ это два конца одного спектра. Один конец это ровно ваш сценарий «настроил один раз»: сервер RCQ можно поднять локально, хоть на старом ноуте или Raspberry Pi в доме, и соседи цепляются к нему по обычному WiFi, без выхода в интернет вообще. Получается приватный «остров» на дом или район, со всем шифрованием и без связи наружу. Другой конец это Radio, когда даже точки доступа нет: телефоны напрямую, ноль инфраструктуры, ценой радиуса.
А вот «связать это всё в единое децентрализованное, чтобы не играть в хакера» это честно самая сложная часть, и красиво её пока никто не закрыл. Мы скорее даём набор кубиков (локальный сервер плюс direct-радио), чем обещаем один волшебный mesh. Но вектор вы описали верно: спрос на локалки при первом же серьёзном рубильнике вырастет очень быстро.
Справедливо, и да: если человек стоит рядом, проще сказать вслух. Radio не про это. Он про координацию ГРУППЫ без интернета, когда вы не все в одной точке.
Во-первых, радиус это не «несколько метров». Несколько метров это BLE-маячок для обнаружения, а сами сообщения идут по Wi-Fi Direct, до сотни метров в прямой видимости. Это этаж здания, двор, небольшая площадь, вагон. Голосом через толпу или сквозь стены вы туда не докричитесь, а текст в комнату доходит всем разом.
Во-вторых, текст делает то, что голос не умеет: тихо (в толпе не хочется орать чувствительное вслух), сразу всем участникам и со структурой (координаты, ссылка, фото, закреплённый план).
Про USB-C приёмопередатчик с антенной на километры: это ровно тот путь, о котором выше писали с Meshtastic. Отдельная LoRa-железка на sub-GHz реально берёт километры, ценой отдельного устройства, низкого битрейта и текста без медиа. Направление интересное, но это другой продукт: ты носишь с собой донгл. Radio сознательно про обратный размен, ноль доп-железа и настройки, телефон уже в кармане, ценой радиуса. Разные инструменты под разные сценарии.
Про чужака в чате против релея: это разные вещи. Когда человек заходит в комнату, он участник и видит сообщения, зашифрованные под ключ комнаты, так и задумано. Релей это другое: твой телефон тащит чужой трафик людей, с которыми ты не общаешься. Даже если содержимое зашифровано, релей видит метаданные (кто рядом с кем, тайминги, размеры), может придержать или подменить, становится точкой для спама и деанона по соседству. Опасна именно роль промежуточного релея, а не сам факт членства в чате.
Про точку доступа с сервером: по сути это ровно то, что Radio и делает, только без ручной настройки. Wi-Fi Direct группа это и есть телефон-хаб, к которому подключаются остальные, но без поднятия AP, без раздачи своего интернета и возни с SSID, и сразу со встроенным шифрованием и анонимной личностью. Инстинкт верный, мы пришли к той же звезде.
Справедливо, спасибо за ссылку, посмотрели. Meshtastic это как раз тот случай, когда городской mesh реально работает: и тебе отдельная LoRa-железка на sub-GHz, низкий битрейт, протокол изначально под многохоп и дальние дистанции и так далее. Я же в статье про другое: стоковый смартфон без дополнительного железа, только BLE и Wi-Fi Direct, где ОС душит фоновую радиоработу, дальность маленькая, и честный многохоп там почти не живёт. Это разные инструменты под разные задачи. Meshtastic берёт дальность ценой отдельного устройства и пропускной способности (текст, не голос с фото), Radio берёт телефон, который уже в кармане, ценой радиуса в один хоп. Формулировку в статье поправлю, чтобы не вводила в заблуждение :)
Briar мы уважаем, и про список «но» вы правы: у любого честного P2P и mesh куча ограничений, мы про это в статье прямо пишем. Разница в центре тяжести.
Briar максимально децентрализован: сервера нет вообще, онлайн через Tor, синхронизация через общих контактов. Цена этого: по сути только Android (на iOS его нет), нет пушей (нужен запущенный Tor-сервис), контакты добавляются обменом ссылками, а Tor часто режут. В итоге, как вы и говорите, в полевых условиях остаётся директ по BT/WiFi.
RCQ по умолчанию это обычный онлайн-мессенджер с E2E (libsignal, forward secrecy, sealed sender) через серверный релей: iOS, Android и веб, доставка офлайн-сообщений из очереди, пуши на iOS (на Android в работе), контакт по короткому UIN, и встроенный обход блокировок (VLESS/Reality), без Tor. А наш Radio это как раз «briar-режим» на случай, когда интернета нет совсем, и у него ровно те же физические ограничения, что у любого P2P по BT/WiFi, мы это не прячем.
Честный размен: у нас есть сервер, у Briar нет. Мы платим за это доверием к серверу (минимизируем его через sealed sender и E2E), но получаем кроссплатформенность, пуши и поведение нормального мессенджера. Briar платит удобством за отсутствие сервера. Это разные точки на кривой «приватность против юзабилити», а не «лучше или хуже» в вакууме.
Это мы еще не в отпуске даже.
История. Тяжёлое это медиа, а оно на телефоне постоянно не лежит: файл это зашифрованный блоб на сервере, клиент тянет по запросу и кэширует, кэш можно чистить. Текст лёгкий даже за годы. Архив старого добавим.
Медиа и IP. Клиент ходит только на свой сервер, не по сторонним URL. Картинка лежит блобом на том же бэкенде и тянется по id. Наружу IP не утекает, свой сервер контент всё равно не видит.
Relay видит IP. Да, любой сервер видит ваш TCP-адрес, без Tor/VPN никак. У нас знание расщеплено: relay видит IP, но не личность и не контент (TLS-туннель), бэкенд видит личность, но IP уже relay. Пул наш, конфиг подписан. Нужен полный контроль над IP, поднимаете свой остров. Выбор relay вручную на радаре.
Яна на relay1, Саша на relay2. Поправлю: такой модели у нас нет специально. Federation и s2s нет, острова изолированы, Яна и Саша общаются только на одном острове. Relay это не роутер между серверами, а дверь обхода блокировок перед одним бэкендом. Какую дверь ни выбери, попадёшь на тот же сервер.
По порядку.
Переустановка и потеря устройства. Да, аккаунт это ключ, сгенерированный на устройстве, без пароля, почты и телефона. Снёс приложение без бэкапа, ключ пропал, 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).
Подход рабочий, но громоздкий: целая VM плюс SSH-туннель плюс per-app routing. Для split-tunnel на 2026-й есть варианты полегче (знаю как минимум несколько):
WireGuard с AllowedIPs. Конфигурируешь WG на хосте, в AllowedIPs указываешь только корпоративные подсети (10.x/8 или какие у вас). Всё что попадает в эти подсети, идёт через WG, остальное напрямую. Не нужна ни VM, ни SOCKS5, ни настройка приложений. Один конфиг :)
Tailscale subnet router. Если корпоративная сеть подключена к Tailscale (или поставлена Tailscale-нода в корп-DMZ как subnet router), на клиенте просто
tailscale up, трафик к корпоративным IP идёт через mesh, остальное напрямую. Из коробки, без правки routing-таблиц вручную.macOS Network Extensions per-app VPN. Если только macOS, нативный API NEAppProxyProvider даёт per-app routing без проксей. Сложнее в реализации, но самое нативное.
Сейчас твой setup решает проблему правильно концептуально, но через три слоя инфраструктуры. WG + AllowedIPs делает то же самое в одном конфиге и гораздо, гораздо эффективнее imho. А так: мое уважение.
Своё не из любви к велосипедам. Matrix и XMPP про федерацию и совместимость, а нам важнее минимум метаданных и анонимность. У них сервер видит состав комнат, граф, presence. У нас sealed sender, сервер не знает даже от кого сообщение. За это и платим отсутствием федерации. Кстати это сразу ответ про s2s: её нет специально, острова это изолированные инстансы, а федерация и есть лишний канал утечки метаданных.
Мультидевайса пока нет, врать не буду. Мультиаккаунт есть (несколько личностей на телефоне), но это другое. На libsignal он ложится естественно, доберёмся.
OIDC не подходит по смыслу: это провайдер, который знает кто ты и когда зашёл. А аккаунт у нас анонимный, без почты и телефона. Регистрация выдаёт UIN и токен под ключ, сгенерированный на устройстве, пароля нет вообще.
Роли пока примитивные: владелец и участники, вся модерация на владельце (кик, закреп, кто может постить, закрыть группу). Полноценных админов и модераторов нет, хотим добавить.
Про эфемерный ключ: вы смотрели v=1, это запасной режим (ECIES) для случая, когда у собеседника ещё нет libsignal-бандла. Боевой путь v=2, там полноценный libsignal: X3DH/PQXDH плюс Double Ratchet, ключей хватает и forward secrecy на месте.
Спасибо, исправили.
Ссылки действительно потерялись при публикации, добавил в конец статьи.
Вот они:
iOS: github.com/rcq-messenger/rcq-ios
Android: github.com/rcq-messenger/rcq-android
Референс сервера: github.com/rcq-messenger/rcq-server-ref
Всё под AGPL-3.0.
По делу всё, не буду спорить.
1. Да, согласен, корректнее сравнивать с VeraCrypt hidden volume, где существование скрытого зависит от введённого ключа. Мейнстрим-мессенджеры тут не пример, признаю.
2. Противоречие в нашей модели угроз ты вскрыл честно. Защиту вижу так: decoy опциональный, и тот, кто его настраивает, явно принимает повышенный риск форс-эскалации в обмен на «есть-что-показать». Кто не хочет такого размена, оставляет просто real-аккаунт без decoy/wipe, тогда RCQ выглядит как обычный мессенджер. Не идеальный ответ, но это пользовательский выбор, а не навязанный default.
3. За идею с серверной генерацией + backdating + «дописыванием в момент открытия» спасибо, об этом мы не думали. Подводные, навскидку: (а) server-side генерация создаёт артефакт связи «decoy -> пользователь» на сервере, по запросу властей всплывает; (б) при border-контроле часто airplane mode, server-side fetch не отработает; (в) ровно кластеризованные «свежие» timestamps сами по себе forensic-artifact. Идея жизнеспособна, но требует тонкого балансирования, возьму в копилку.
Спасибо за честный разбор. Редко видишь такое.