Андроид и десктоп в планах, но не в работе прямо сейчас (можно сказать, что в полу-процессе, но и Рим не строился за один день). Нас трое в свободное время, тянуть несколько платформ параллельно не получается, поэтому начали с одной и довели до состояния, за которое не стыдно. Когда iOS-версия стабилизируется, возьмёмся за Android. Если кто-то из комьюнити начнёт раньше, поможем чем сможем, исходники открыты под AGPL. (на самом деле уже нашлись люди, которые готовы присоединиться)
Про Apple и Роскомнадзор. Да, риск реальный, и мы про него знаем. Apple уже снимал из российского App Store кучу всего, спорить тут не о чем. Что мы с этим делаем:
Приложение опубликовано не российским разработчиком, основной канал распространения это глобальный App Store, не RU-стор. Российский пользователь ставит через зарубежный Apple ID или через TestFlight.
iOS-клиент полностью открыт под AGPL, репозиторий на GitHub. Если Apple когда-нибудь выкинет нас отовсюду, код всё равно остаётся, и кто-то соберёт под другим developer-аккаунтом. В EU уже есть альт-сторы, на Android после релиза Android-клиента такой проблемы вообще не будет.
Параллельно делаем web-клиент (пока send-only, доразовьём). UX там хуже, но это аварийный канал, который Apple не контролирует.
Это не панацея, конечно. Apple может одним движением выпилить нас, и часть пользователей потеряем. Но архитектура построена так, чтобы это означало «потеряли канал распространения», а не «потеряли всё».
Про iMessage. Он работает только между айфонами, на Android уже нет (зелёные пузыри уходят как SMS). И встроенного обхода блокировок у него тоже нет, его трафик идёт к серверам Apple, у которых в РФ свои особенности.
То есть ту задачу, под которую мы делаем RCQ (кроссплатформенно, цензуроустойчиво, без привязки к номеру телефона), iMessage просто не решает. Иначе и Signal, и Telegram на iPhone никому не были бы нужны, а у всех они есть.
Хороший вопрос. Если правильно помню, у Yggdrasil identity это Ed25519-ключ узла, а IPv6-адрес узла однозначно из него выводится. То есть identity у них per-node (на каждую инсталляцию своя), и решает задачу «как одному узлу маршрутизировать пакеты другому, зная только его публичный ключ». Полезная штука, но довольно специфическая.
Для мессенджера нужно несколько вещей сверху, которых у Yggdrasil просто нет:
X3DH для асинхронного key agreement: signed prekey и пачка one-time prekeys лежат на сервере, чтобы Федор мог написать Яне, пока Яна оффлайн.
Double Ratchet: forward secrecy и post-compromise security на каждом сообщении. Yggdrasil-уровень это пакеты, понятия «сессия мессенджера» там в принципе не существует.
Sender Keys для эффективной групповой криптографии (без них каждое групповое сообщение приходится шифровать по числу участников).
Sealed sender для метаданных «кто кому».
И ещё момент: пользователь у нас один, а устройств может быть несколько, у каждого свой session-ключ. Yggdrasil-identity жёстко прибита к узлу, я не уверен, можно ли это туда нормально натянуть.
Поэтому я бы не сказал, что libsignal и Yggdrasil это альтернативы. Они скорее на разных слоях: libsignal закрывает крипту мессенджера, Yggdrasil (или Reality, или что-то ещё) сидит ниже и таскает байты. Кстати, Tox over Yggdrasil уже существует, и там Tox-крипта тоже осталась своя, Yggdrasil её не заменял.
Ну и честно говоря, переписывать X3DH + Double Ratchet + Sealed Sender с нуля втроём в свободное время мы бы не вытянули (даже продвинутый ИИ -не всесилен). libsignal проверен в Signal и WhatsApp, аудитов на нём прилично, так что взяли его не от любви, а из расчёта.
Пока только iOS, да. Тянуть две платформы параллельно втроём в сайд-проекте не получалось, поэтому Android осознанно отложен (но в процессе все равно). Протокол + бэкенд открыты, спецификация в репозитории, так что если кто-то из комьюнити начнёт Android-клиент раньше нас, поможем чем сможем. Сами вернёмся к Android, когда iOS-версия стабилизируется.
Да, ИИ используем активно, и в коде, и в текстах, а кто его сейчас не использует, интересно? Команда из трёх человек, базируемся в Израиле, у каждого основная работа в IT, RCQ это сайд-проект в свободное время. Шипить мессенджер втроём по вечерам без буста от LLM было бы очень медленно, поэтому и в репозитории следы видны, и в комментариях тон такой. Скрывать это смысла нет.
По «шаблонному описанию преимуществ»: техническая статья про обход блокировок неизбежно строится вокруг сравнения с альтернативами (MTProto-proxy, Shadowsocks, классический VPN). Без сравнения остаётся голый список технологий без объяснения, зачем они. По «продают, а он бесплатный»: исходники iOS-клиента открыты под AGPL-3.0 на github.com/rcq-messenger/rcq-ios, бэкенд крутится на нашем железе за наш счёт. Если бы продавали, был бы прайс-лист :)
Первое, сам транспорт. У Telegram MTProto-proxy, это отдельный протокол. DPI распознаёт его по эвристикам (длины пакетов, тайминги), часть провайдеров так и делает. У нас VLESS+Reality: handshake идёт от лица реального публичного сайта (yandex.com, microsoft.com и т.п.), и для DPI трафик неотличим от обычного HTTPS к этому сайту, пока не пойдёт активное зондирование конкретного соединения. То есть мы прячемся в шум легитимных TLS-сессий, а не имеем свой опознаваемый протокол.
Второе, раздача списков. Telegram пушит прокси-листы через t.me-ссылки, in-app и (как вы и сказали) push-уведомления. У нас планируется signed remote config с Ed25519: публичный ключ зашит в бинарник, конфиг отдаётся CDN, клиент проверяет подпись. Подменить конфиг на стороне сети нельзя, даже если CDN под MITM. Транспорт уже в проде, signed-config в активной разработке (прямо сейчас внедряем, ибо пользователи в некоторых регионах уже сталкиваются с проблемой блокировки).
И ваш второй пункт абсолютно справедлив. Telegram сейчас собирает весь поток внимания регулятора, у нас этого внимания пока нет, и это даёт окно. Когда оно появится, выручит ротация и большой коллатерал по легитимным сайтам Reality: заблокировать наш транспорт без блокировки условного yandex.com технически непросто.
Логика «все мессенджеры уже есть» одинаково применима к 2010-му (зачем Signal, есть WhatsApp), 2013-му (зачем Telegram), 2014-му (зачем Threema). Каждый раз ниша находилась.
Конкретно наша: люди в регионах с сетевой цензурой (РФ, СНГ, Иран), где WhatsApp/Signal/Telegram режут на сетевом уровне по TLS-фингерпринту, а Jami и подобные DHT-решения не доставляют офлайн-сообщения и не имеют встроенного обхода блокировок. RCQ закрывает именно это: libsignal + sealed sender + VLESS/Reality внутри приложения, без отдельного VPN.
Регистрация по UIN, без номера телефона и паспорта. Плюс Bluetooth-mesh работает в Иране во время shutdown-ов, когда интернета нет вообще.
Network effect это правда, у любого нового мессенджера эта проблема. В том числе была у Telegram, Signal, Discord (и др.) когда они стартовали. Это не повод не пытаться, а повод делать аккуратно под конкретную аудиторию.
Yggdrasil это mesh IP-routing, замена транспортного слоя между узлами. Над ним всё равно нужен мессенджер: identity, ключи, доставка офлайн-сообщений, push, медиа. Это разные слои задачи, одно другое не заменяет.
Хороший и ожидаемый вопрос, это ровно тот сценарий из-за которого мы и затевали эту архитектуру.
IP-адрес relay для нас расходник, не постоянная инфраструктура. Закрывается так: пул relay в разных облачных провайдерах (один сгорает, остальные работают), конкретный список приложение получает из удалённого подписанного конфига (Ed25519, публичный ключ верификации зашит в само приложение), а не из кода. Когда IP сгорает, мы публикуем новый конфиг с новым адресом, клиент подхватывает его на следующем коннекте, без релиза в App Store. Конфиг раздаётся через CDN с большим коллатералом на легитимные сайты, чтобы и его не отрубили.
Сам VLESS+Reality транспорт уже в проде, ротация и signed-config в активной разработке. И честно: ни один обход не «навсегда», это гонка. Архитектура построена так, чтобы реакция на сгоревший IP занимала часы (даже меньше), а не дни/недели через ревью Apple.
Мы это команда, которая делает RCQ. В RuStore и в реестр ОРИ принципиально не идём: нам неинтересно строить ещё один MAX или его уменьшенную, деградированную копию. Базируемся не в РФ, серверы тоже за пределами.
По умолчанию у нас E2E-шифрование (libsignal, sealed sender) и встроенный обход блокировок (VLESS + Reality через sing-box прямо внутри приложения). Идея простая: пользователю в РФ, Иране или Китае не должно приходиться поверх ставить VPN, который завтра тоже срежут. Подробнее писали во вчерашней статье про обход блокировок.
К чужому подходу без оценок, у Ласточки своя стратегия. Просто не наша.
В Telegram уже есть свои MTProto-прокси для похожей задачи, но они маскируют именно Telegram-протокол. Reality универсальнее: его можно завернуть вокруг любого outbound-трафика. Поэтому в нашем случае это и сработало проще, чем городить свою обфускацию.
Никак специально не режет. И статья этого не утверждает.
Реальность проще и хуже. РКН и операторы по его предписаниям фильтруют не «по продуктам», а по диапазонам и фингерпринтам. Когда блочат сеть провайдера, типовой SNI-паттерн или конкретный TLS-fingerprint, в этот фильтр попадают сразу десятки мелких сервисов которых никто индивидуально не «замечал». Это collateral, а не таргетинг.
Reality в этом контексте нужен ровно потому, что «правильная репутация» от такого collateral'а не спасает. Не важно знаменит ли ты, важно как твой ClientHello выглядит на DPI. Если как обычный мессенджер с cloud-IP, попадёшь в общий фильтр. Если как трафик к microsoft.com, пройдёшь.
То есть статья не про «РКН охотится за нами», а про «как сделать так, чтобы DPI вообще не различал что это мессенджер».
Информация
В рейтинге
579-й
Откуда
Тель-Авив, Тель-Авив, Израиль
Дата рождения
Зарегистрирован
Активность
Специализация
Фулстек разработчик, Инженер по обеспечению качества
Андроид и десктоп в планах, но не в работе прямо сейчас (можно сказать, что в полу-процессе, но и Рим не строился за один день). Нас трое в свободное время, тянуть несколько платформ параллельно не получается, поэтому начали с одной и довели до состояния, за которое не стыдно. Когда iOS-версия стабилизируется, возьмёмся за Android. Если кто-то из комьюнити начнёт раньше, поможем чем сможем, исходники открыты под AGPL. (на самом деле уже нашлись люди, которые готовы присоединиться)
Про Apple и Роскомнадзор. Да, риск реальный, и мы про него знаем. Apple уже снимал из российского App Store кучу всего, спорить тут не о чем. Что мы с этим делаем:
Приложение опубликовано не российским разработчиком, основной канал распространения это глобальный App Store, не RU-стор. Российский пользователь ставит через зарубежный Apple ID или через TestFlight.
iOS-клиент полностью открыт под AGPL, репозиторий на GitHub. Если Apple когда-нибудь выкинет нас отовсюду, код всё равно остаётся, и кто-то соберёт под другим developer-аккаунтом. В EU уже есть альт-сторы, на Android после релиза Android-клиента такой проблемы вообще не будет.
Параллельно делаем web-клиент (пока send-only, доразовьём). UX там хуже, но это аварийный канал, который Apple не контролирует.
Это не панацея, конечно. Apple может одним движением выпилить нас, и часть пользователей потеряем. Но архитектура построена так, чтобы это означало «потеряли канал распространения», а не «потеряли всё».
Про iMessage. Он работает только между айфонами, на Android уже нет (зелёные пузыри уходят как SMS). И встроенного обхода блокировок у него тоже нет, его трафик идёт к серверам Apple, у которых в РФ свои особенности.
То есть ту задачу, под которую мы делаем RCQ (кроссплатформенно, цензуроустойчиво, без привязки к номеру телефона), iMessage просто не решает. Иначе и Signal, и Telegram на iPhone никому не были бы нужны, а у всех они есть.
Хороший вопрос. Если правильно помню, у Yggdrasil identity это Ed25519-ключ узла, а IPv6-адрес узла однозначно из него выводится. То есть identity у них per-node (на каждую инсталляцию своя), и решает задачу «как одному узлу маршрутизировать пакеты другому, зная только его публичный ключ». Полезная штука, но довольно специфическая.
Для мессенджера нужно несколько вещей сверху, которых у Yggdrasil просто нет:
X3DH для асинхронного key agreement: signed prekey и пачка one-time prekeys лежат на сервере, чтобы Федор мог написать Яне, пока Яна оффлайн.
Double Ratchet: forward secrecy и post-compromise security на каждом сообщении. Yggdrasil-уровень это пакеты, понятия «сессия мессенджера» там в принципе не существует.
Sender Keys для эффективной групповой криптографии (без них каждое групповое сообщение приходится шифровать по числу участников).
Sealed sender для метаданных «кто кому».
И ещё момент: пользователь у нас один, а устройств может быть несколько, у каждого свой session-ключ. Yggdrasil-identity жёстко прибита к узлу, я не уверен, можно ли это туда нормально натянуть.
Поэтому я бы не сказал, что libsignal и Yggdrasil это альтернативы. Они скорее на разных слоях: libsignal закрывает крипту мессенджера, Yggdrasil (или Reality, или что-то ещё) сидит ниже и таскает байты. Кстати, Tox over Yggdrasil уже существует, и там Tox-крипта тоже осталась своя, Yggdrasil её не заменял.
Ну и честно говоря, переписывать X3DH + Double Ratchet + Sealed Sender с нуля втроём в свободное время мы бы не вытянули (даже продвинутый ИИ -не всесилен). libsignal проверен в Signal и WhatsApp, аудитов на нём прилично, так что взяли его не от любви, а из расчёта.
Пока только iOS, да. Тянуть две платформы параллельно втроём в сайд-проекте не получалось, поэтому Android осознанно отложен (но в процессе все равно). Протокол + бэкенд открыты, спецификация в репозитории, так что если кто-то из комьюнити начнёт Android-клиент раньше нас, поможем чем сможем. Сами вернёмся к Android, когда iOS-версия стабилизируется.
Да, ИИ используем активно, и в коде, и в текстах, а кто его сейчас не использует, интересно? Команда из трёх человек, базируемся в Израиле, у каждого основная работа в IT, RCQ это сайд-проект в свободное время. Шипить мессенджер втроём по вечерам без буста от LLM было бы очень медленно, поэтому и в репозитории следы видны, и в комментариях тон такой. Скрывать это смысла нет.
По «шаблонному описанию преимуществ»: техническая статья про обход блокировок неизбежно строится вокруг сравнения с альтернативами (MTProto-proxy, Shadowsocks, классический VPN). Без сравнения остаётся голый список технологий без объяснения, зачем они. По «продают, а он бесплатный»: исходники iOS-клиента открыты под AGPL-3.0 на github.com/rcq-messenger/rcq-ios, бэкенд крутится на нашем железе за наш счёт. Если бы продавали, был бы прайс-лист :)
Первое, сам транспорт. У Telegram MTProto-proxy, это отдельный протокол. DPI распознаёт его по эвристикам (длины пакетов, тайминги), часть провайдеров так и делает. У нас VLESS+Reality: handshake идёт от лица реального публичного сайта (yandex.com, microsoft.com и т.п.), и для DPI трафик неотличим от обычного HTTPS к этому сайту, пока не пойдёт активное зондирование конкретного соединения. То есть мы прячемся в шум легитимных TLS-сессий, а не имеем свой опознаваемый протокол.
Второе, раздача списков. Telegram пушит прокси-листы через t.me-ссылки, in-app и (как вы и сказали) push-уведомления. У нас планируется signed remote config с Ed25519: публичный ключ зашит в бинарник, конфиг отдаётся CDN, клиент проверяет подпись. Подменить конфиг на стороне сети нельзя, даже если CDN под MITM. Транспорт уже в проде, signed-config в активной разработке (прямо сейчас внедряем, ибо пользователи в некоторых регионах уже сталкиваются с проблемой блокировки).
И ваш второй пункт абсолютно справедлив. Telegram сейчас собирает весь поток внимания регулятора, у нас этого внимания пока нет, и это даёт окно. Когда оно появится, выручит ротация и большой коллатерал по легитимным сайтам Reality: заблокировать наш транспорт без блокировки условного yandex.com технически непросто.
Логика «все мессенджеры уже есть» одинаково применима к 2010-му (зачем Signal, есть WhatsApp), 2013-му (зачем Telegram), 2014-му (зачем Threema). Каждый раз ниша находилась.
Конкретно наша: люди в регионах с сетевой цензурой (РФ, СНГ, Иран), где WhatsApp/Signal/Telegram режут на сетевом уровне по TLS-фингерпринту, а Jami и подобные DHT-решения не доставляют офлайн-сообщения и не имеют встроенного обхода блокировок. RCQ закрывает именно это: libsignal + sealed sender + VLESS/Reality внутри приложения, без отдельного VPN.
Регистрация по UIN, без номера телефона и паспорта. Плюс Bluetooth-mesh работает в Иране во время shutdown-ов, когда интернета нет вообще.
Network effect это правда, у любого нового мессенджера эта проблема. В том числе была у Telegram, Signal, Discord (и др.) когда они стартовали. Это не повод не пытаться, а повод делать аккуратно под конкретную аудиторию.
Yggdrasil это mesh IP-routing, замена транспортного слоя между узлами. Над ним всё равно нужен мессенджер: identity, ключи, доставка офлайн-сообщений, push, медиа. Это разные слои задачи, одно другое не заменяет.
Исправим, спасибо.
Хороший и ожидаемый вопрос, это ровно тот сценарий из-за которого мы и затевали эту архитектуру.
IP-адрес relay для нас расходник, не постоянная инфраструктура. Закрывается так: пул relay в разных облачных провайдерах (один сгорает, остальные работают), конкретный список приложение получает из удалённого подписанного конфига (Ed25519, публичный ключ верификации зашит в само приложение), а не из кода. Когда IP сгорает, мы публикуем новый конфиг с новым адресом, клиент подхватывает его на следующем коннекте, без релиза в App Store. Конфиг раздаётся через CDN с большим коллатералом на легитимные сайты, чтобы и его не отрубили.
Сам VLESS+Reality транспорт уже в проде, ротация и signed-config в активной разработке. И честно: ни один обход не «навсегда», это гонка. Архитектура построена так, чтобы реакция на сгоревший IP занимала часы (даже меньше), а не дни/недели через ревью Apple.
Мы это команда, которая делает RCQ. В RuStore и в реестр ОРИ принципиально не идём: нам неинтересно строить ещё один MAX или его уменьшенную, деградированную копию. Базируемся не в РФ, серверы тоже за пределами.
По умолчанию у нас E2E-шифрование (libsignal, sealed sender) и встроенный обход блокировок (VLESS + Reality через sing-box прямо внутри приложения). Идея простая: пользователю в РФ, Иране или Китае не должно приходиться поверх ставить VPN, который завтра тоже срежут. Подробнее писали во вчерашней статье про обход блокировок.
К чужому подходу без оценок, у Ласточки своя стратегия. Просто не наша.
Все верно, лучше иметь альтернативу, которая работает без VPN, вроде нас:) И мы не в РФ.
В Telegram уже есть свои MTProto-прокси для похожей задачи, но они маскируют именно Telegram-протокол. Reality универсальнее: его можно завернуть вокруг любого outbound-трафика. Поэтому в нашем случае это и сработало проще, чем городить свою обфускацию.
UPD: задумывалось как ответ на коммент @art3012, промахнулся кнопкой. Дублирую в правильном треде.
Никак специально не режет. И статья этого не утверждает.
Реальность проще и хуже. РКН и операторы по его предписаниям фильтруют не «по продуктам», а по диапазонам и фингерпринтам. Когда блочат сеть провайдера, типовой SNI-паттерн или конкретный TLS-fingerprint, в этот фильтр попадают сразу десятки мелких сервисов которых никто индивидуально не «замечал». Это collateral, а не таргетинг.
Reality в этом контексте нужен ровно потому, что «правильная репутация» от такого collateral'а не спасает. Не важно знаменит ли ты, важно как твой ClientHello выглядит на DPI. Если как обычный мессенджер с cloud-IP, попадёшь в общий фильтр. Если как трафик к microsoft.com, пройдёшь.
То есть статья не про «РКН охотится за нами», а про «как сделать так, чтобы DPI вообще не различал что это мессенджер».