⚠️ Дисклеймер

Важное уведомление

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

Автор не распространяет готовые средства обхода блокировок и не призывает к их использованию. Любые практические реализации, описанные в статье, являются гипотетическими и требуют от пользователя самостоятельной оценки соответствия законодательству своей страны.

Ответственность за применение полученных знаний лежит исключительно на пользователе.

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

⏱️ Коротко (2 минуты)

Проблема
Классические P2P-мессенджеры (Jami, Tox):

• плохо работают за CGNAT;

• зависят от централизованных TURN-серверов;

• легко блокируются через DPI;

• не учитывают whitelist-модели.

Ключевая идея
❗ Не существует «неблокируемого» протокола.
✅ Существует система, которая ломается частично, но не полностью.

Решение
Многоуровневый клиент с fallback-архитектурой:

1. Прямое P2P (Hyperswarm / librats)

2. Ретрансляция через пиров

3. Маскированный транспорт (AmneziaWG, Zapret)

4. Асинхронный fallback

Что получаем?
Не «абсолютно неблокируемый» мессенджер (такого не бывает), а систему, которая:

• повышает стоимость блокировки,

• снижает точность DPI,

• остаётся работоспособной даже при жёстких «белых списках».

? Вступление

Это продолжение моей предыдущей статьи о Jami в России. Там я разбирал, почему классический P2P-мессенджер испытывает трудности в российских сетях (CGNAT, блокировки TURN-серверов, устаревший ICE), и предлагал направления для модернизации.

Ключевой вывод: интернет больше не P2P-friendly среда. Причины — CGNAT, DPI, whitelist-модели, особенности мобильных сетей.

В комментариях меня справедливо критиковали: «QUIC уже блокируют», «IPv6 есть не у всех», «белые списки всё равно всё убьют». Спасибо, я услышал. Вместо того чтобы пытаться «допилить» Jami на C++, я нашёл готовую открытую платформу — Holepunch / Pear Runtime. На ней уже работает мессенджер Keet, но его исходный код мне найти не удалось.

Уточнение про Keet: в официальных GitHub-репозиториях организации Holepunch (github.com/holepunchto) находятся Pear Runtime, Hypercore, Hyperswarm, Bare. Репозитория «keet» или «keet-app» в открытом доступе нет. Это означает, что сам клиент Keet не является Open Source, хотя платформа под ним — открыта. Поэтому мы не можем форкнуть Keет или легально модифицировать его. Вместо этого мы создаём новый открытый клиент с нуля на той же платформе.

Про «белые списки всё равно убьют»: возможно. Но задача этой статьи — исследовать технологии, которые могут повысить стоимость блокировки и снизить точность DPI. Если не пытаться — точно ничего не будет.

? Часть 1. Фундамент: экосистема Holepunch / Pear Runtime

Holepunch — это компания, созданная при поддержке Tether и Bitfinex, которая предоставляет разработчикам инструменты для создания P2P-приложений. Их флагманский продукт — Pear Runtime — это полностью открытая среда для разработки, развёртывания и запуска P2P-приложений на десктопе, в терминале и, что самое важное для нас, на мобильных устройствах. Весь код экосистемы (более 100 репозиториев) открыт и доступен на GitHub под лицензиями MIT и Apache 2.0:

• Pear Runtime (github.com/holepunchto/pear)

• Hypercore (github.com/holepunchto/hypercore)

• Hyperswarm (github.com/holepunchto/hyperswarm)

• Bare (github.com/holepunchto/bare)

В основе Pear Runtime лежат ключевые строительные блоки:

• Hyperswarm (DHT + hole-punching). Распределённая хеш-таблица для поиска пиров, использующая UDP hole-punching. Теоретически способна устанавливать прямые соединения даже за сложными NAT, однако эффективность в условиях CGNAT и симметричного NAT требует практических измерений в целевых сетях.

• Hypercore. Безопасный, распределённый журнал с добавлением (append-only log) для хранения данных — идеально подходит для истории сообщений.

• Bare. Небольшой и модульный JavaScript-рантайм для десктопа и мобильных устройств.

Вывод: фундамент у нас есть, он открыт и современен.

? Часть 2. Архитектура выживания: 5 слоёв вместо «серебряной пули»

Ошибка большинства решений — попытка найти «магический транспорт» (QUIC, IPv6, свой протокол). Реальность такова, что любой отдельный слой ломается. DPI адаптируется, whitelist'ы расширяются, CGNAT никуда не денется.

Работает только комбинация слоёв, где отказ одного уровня не убивает всю систему, а лишь снижает её функциональность. Мы проектируем управляемую деградацию.

Наша система делится на 5 уровней:

1. Core (P2P-ядро)
Задача: поиск пиров, установка соединений, передача данных.
Наш выбор: Hyperswarm (DHT + hole-punching) для быстрого прототипа. В перспективе — librats (C++) (github.com/DEgITx/librats) с протоколом DCUtR для максимальной производительности на Android и экономии батареи. На текущий момент это гипотеза, требующая сравнительного тестирования. Однако уже есть обнадеживающие данные: по замерам автора, при 100 подключенных пирах librats потребляет около 1.4 МБ ОЗУ и 1% CPU, в то время как JS-реализация libp2p в аналогичных условиях требует 400 МБ ОЗУ и загружает процессор на 100% (источник).

2. Transport (транспорт)
Задача: доставить трафик любым доступным способом.
Режимы: UDP (если разрешён), TCP, WebSocket over TLS (wss://) как основной fallback-транспорт, маскирующийся под обычный HTTPS. QUIC не используется в MVP из-за активной блокировки в РФ.

3. Obfuscation (маскировка)
Ключевой слой. Недостаточно просто «включить TLS» — DPI давно анализирует поведение: отпечатки JA3/JA4, тайминги пакетов, заголовки. Нужна имитация нормального веб-клиента с корректным TLS fingerprint и правдоподобными таймингами.

⚠️ Важное ограничение: большинство инструментов обфускации (Zapret, AmneziaWG, TrustTunnel) требуют системных привилегий (root) или работают как отдельные VPN-сервисы. В рамках MVP на Android они не встраиваются в приложение. Вместо этого:

• На первом этапе используется только WebSocket over TLS с корректным TLS-фарпринтом (имитация обычного HTTPS).

• Для глубокой обфускации пользователь может запустить Zapret или AmneziaWG отдельно (например, через стороннее приложение) и направить трафик мессенджера через него.

• В будущем возможно исследование встроенных лёгких обфускаторов (случайная задержка, фрагментация в userspace) без root.

Инструменты для будущих исследований (не входят в MVP):

• TrustTunnel — полная имитация HTTPS (требует VPN-режима).

• AmneziaWG — защита WireGuard-трафика (отдельный клиент).

• Zapret — фрагментация пакетов (требует root или TUN).

• ByeByeDPI — обход DPI на Android без root (byebyedpi.com).

• White Noise (Nostr) — альтернативная DHT для сигналинга (github.com/parres-hq/whitenoise_flutter).

4. Relay (ретрансляция)
Задача: обеспечить связь, когда прямое P2P невозможно (CGNAT, блокировка UDP).
Решение: ретрансляция через других пиров. Любой пользователь с публичным IP может стать relay-узлом. Это аналог TURN, но без фиксированных IP и центральных серверов, которые легко блокируются. Практическая реализация relay-сети требует решения задач контроля нагрузки, защиты от злоупотреблений и механизмов мотивации узлов. В MVP используется простейший relay через WebSocket-сервер (один или несколько), который не является P2P, но позволяет проверить концепцию.

5. Fallback (план Б)
Задача: сохранить возможность обмена сообщениями даже в условиях жёсткого whitelist'а, когда всё остальное сломано.
Решение: асинхронная доставка через HTTPS. При тотальном whitelist, когда разрешены только определённые домены (например, vk.com, yandex.ru), клиент может использовать публичные HTTPS-ретрансляторы, размещённые на этих доменах. Сообщения передаются в зашифрованном виде через обычные POST-запросы. Система теряет real-time, но не умирает полностью.

Как это работает технически: Клиент получает список доменов из «белых зон» (например, через предустановленный файл или через DoH). Для каждого домена проверяется доступность, и если сервер-ретранслятор развёрнут на этом домене (или клиент использует легитимный сервис как прокси), сообщения отправляются через HTTPS. Разумеется, это снижает приватность (ретранслятор видит метаданные), но сохраняет связность.

⚠️ Часть 3. Ответ на главный вопрос: Whitelist

Это самый важный сценарий. Что произойдёт при жёстком whitelist'е, когда разрешён только ограниченный список доменов и HTTPS к «доверенным» сервисам?

Вывод: при whitelist'е real-time может не работать, но система деградирует в async-режим, а не умирает полностью. Для этого необходимо заранее развернуть ретрансляторы на доменах, которые гарантированно не блокируются (например, публичные облачные сервисы РФ).

?️ Часть 4. План исследований: строим экспериментальный клиент

Мы не форкаем Keet. Мы создаём новый клиент с нуля, используя открытую платформу Pear Runtime, и исследуем в нём механизмы повышения устойчивости к цензуре.

Этапы разработки:

1. Прототип (быстрый старт): собираем клиент на базе Pear Runtime с Hyperswarm для P2P и Hypercore для хранения сообщений. Тестируем базовые слои маскировки (только WebSocket fallback, без сложной обфускации).

2. Экспериментальная ветка (production-уровень): исследуем замену Hyperswarm на librats (C++) для повышения производительности и экономии батареи на Android. Интеграция возможна через Node.js addon или отдельный нативный сервис с IPC.

Шаг 1. Берём открытую платформу Pear Runtime
Уже доступно: Hyperswarm, Hypercore, Bare.

Шаг 2. Добавляем ретрансляцию через пиров (relay peers)
Простой прокси-слой поверх Hyperswarm, позволяющий пиру с публичным IP ретранслировать трафик для других. Практическая реализация потребует решения задач контроля нагрузки, защиты от злоупотреблений и механизмов мотивации узлов. В MVP используется простой WebSocket-ретранслятор на VPS (централизованный, но временный).

Шаг 3. Маскировка трафика — используем готовые open-source компоненты
Реалистичный подход: В первой версии клиента не будет встроенной обфускации через Zapret/AmneziaWG/TrustTunnel. Вместо этого:

• Основной транспорт — WebSocket over TLS (wss://) с настройками, имитирующими обычный браузер (поддержка TLS-фарпринта).

• Пользователь может запустить внешние инструменты (например, Zapret) самостоятельно, если у него есть root или административные привилегии.

• В долгосрочной перспективе исследуем возможность встраивания лёгкой обфускации (случайные тайминги, фрагментация на уровне приложения).

Таблица инструментов для будущих исследований (не входит в MVP):

Важное уточнение по Nostr: релеи используются только для обнаружения пиров и обмена сигнальной информацией; сами сообщения передаются напрямую P2P. Nostr не рассматривается как основной транспорт или гарантированный канал доставки, а лишь как вспомогательный механизм сигналинга.

Пример концептуальной реализации гибридного транспорта:

// Инициализация P2P-сети
const swarm = new Hyperswarm();
swarm.join(topic, { announce: true, lookup: true });

swarm.on('connection', (socket) => {
  console.log('Direct P2P connection established');
  handleStream(socket);
});

// Fallback: если прямое соединение не устанавливается за N секунд
setTimeout(() => {
  if (!directConnectionEstablished) {
    console.log('Falling back to WebSocket relay');
    const ws = new WebSocket('wss://relay.example.com');
    ws.onopen = () => handleStream(ws);
  }
}, 5000);

Этот упрощённый пример демонстрирует логику: пробуем P2P, при неудаче переключаемся на ретранслятор. Реальная реализация потребует обработки переподключений, аутентификации и шифрования.

Шаг 4. Поддержка IPv6
Добавляем прямые IPv6-соединения и fallback на IPv4 с hole-punching. По данным RIPE NCC и Google, проникновение IPv6 в России на начало 2026 года оценивается в ~3–5%, при этом покрытие крайне неоднородно по регионам и операторам. IPv6 рассматривается как полезный, но не основной транспорт.

Шаг 5. Альтернативные подходы к обходу CGNAT

• librats (github.com/DEgITx/librats) — высокопроизводительная C++ библиотека, замена libp2p.

• DCUtR — протокол установки прямых соединений за NAT через апгрейд с relay-соединения до прямого, специфицированный в libp2p.

• Другие технологии: Stunmesh-go, Yggdrasil, Tailscale/ZeroTier.

Вывод: начинаем с Hyperswarm для быстрого прототипа, но в экспериментальной ветке сразу исследуем librats как замену для production-версии.

Шаг 6 (опциональный). Защита метаданных
Многоуровневое шифрование (луковая маршрутизация) для цепочек ретрансляторов.

Шаг 7. Минималистичный интерфейс
Контакт-лист, диалоги, онлайн-статус.

Шаг 8. Сборка Android APK и публикация исходников
Собираем .apk, выкладываем на GitHub под GPLv3 или MIT.

Ориентир для Android-разработки: проект Zemzeme — форк Bitchat, объединяющий Bluetooth Mesh, libp2p и Nostr (github.com/whisperbit-labs/zemzeme-android).

? Шаг 9. План верификации гипотезы (предлагаемые эксперименты)

Любая архитектура остаётся гипотезой, пока не проверена в реальных условиях. Вот минимальный набор экспериментов, который позволит оценить жизнеспособность подхода:

Эксперимент 1: Стабильность P2P-соединений

• Что делаем: Запускаем два клиента Hyperswarm за разными типами NAT (домашний Wi-Fi, мобильный CGNAT) и измеряем процент успешных прямых соединений, а также время установки связи.

• Метрики: Успешность hole-punching (ориентир: согласно крупному исследованию сети IPFS, протокол DCUtR обеспечивает успех в ~70% ± 7% случаев; наша цель — достичь схожих показателей в сетях РФ). Задержка до первого сообщения (<2 с).

Эксперимент 2: Эффективность WebSocket-fallback

• Что делаем: Принудительно отключаем UDP, заставляя клиентов использовать wss:// через простой ретранслятор на VPS. Измеряем задержку доставки сообщений и сравниваем с прямым P2P.

• Метрики: Дополнительная задержка <500 мс, успешность доставки >95%.

Эксперимент 3: Устойчивость к DPI (упрощённый)

• Что делаем: Пропускаем WebSocket over TLS через реальные сети с DPI (тестируем в разных регионах РФ, просим добровольцев). Анализируем, детектируется ли трафик как не-HTTP.

• Метрики: Отсутствие блокировок на протяжении 1 часа сессии в 10 различных сетях.

Эксперимент 4: Android-совместимость

• Что делаем: Тестируем работу Foreground Service на разных версиях Android (12, 13, 14, 15) в режиме ожидания. Замеряем расход батареи за час работы P2P-ядра (сравниваем JS-версию Hyperswarm и гипотетическую C++ librats).

• Метрики: Расход батареи <10% за час активной переписки.

Приоритеты: На первом этапе критически важно подтвердить работоспособность связки Hyperswarm + WebSocket-fallback. Без этого всё остальное не имеет смысла. Маскировка и альтернативные каналы — это второй приоритет, который имеет смысл подключать только после того, как базовый транспорт доказал свою живучесть.

? Отдельная исследовательская гипотеза: WebRTC-туннель через легитимные сервисы

В качестве отдельного направления исследований можно рассмотреть возможность туннелирования трафика через WebRTC DataChannel поверх публичных сервисов видеозвонков. Техническая идея заключается в том, чтобы установить WebRTC-соединение внутри легитимного звонка (например, ВК или Яндекс.Телемост) и передавать через него зашифрованные данные мессенджера.

Важно: Данный подход рассматривается исключительно как исследовательская гипотеза и не входит в базовую архитектуру MVP. Он поднимает сложные вопросы, связанные с политиками использования сторонних сервисов, и требует отдельного юридического и этического анализа.

Несмотря на обилие перечисленных технологий, для начала достаточно минимальной конфигурации: Hyperswarm + WebSocket fallback + relay peers. Все остальные компоненты добавляются по мере необходимости.

? Часть 5. Технические риски

1. Bare на Android. Нет готового pear-android SDK. Решение: Capacitor/Cordova для упаковки веб-приложения или JNI-обёртки.

2. UDP и Android Doze mode. Использовать WorkManager или WebSocket fallback.

3. Фоновая работа (Foreground Service). Обязателен постоянный сервис с уведомлением, иначе Android убьёт процесс. Важные ограничения: начиная с Android 12 запрещён запуск foreground service из фона в большинстве случаев; с Android 14 требуется явно указывать тип сервиса (serviceType) и соответствующие permissions; в Android 15 для некоторых типов FGS введены лимиты по времени работы. Дополнительно следует учитывать агрессивные политики энергосбережения у некоторых производителей (OEM), которые могут завершать фоновые процессы даже при использовании Foreground Service.

4. Обновление bootstrap-узлов. Зашивать запасные домены, получать список через HTTPS (GitHub Pages) или DNS-over-HTTPS.

5. Подмена TLS fingerprint. В Node.js/Bare нет готового решения; на первом этапе — WebSocket fallback.

6. Юридические риски. Явное предупреждение при первом запуске.

7. Совместимость с librats/libp2p. Требуется сравнительное тестирование.

8. Интеграция внешних обфускаторов. Сначала встроенный WebSocket fallback, затем исследовать udp2raw, wstunnel, Zapret. Однако для Android без root интеграция Zapret и аналогичных невозможна, поэтому они остаются за рамками клиента.

9. Проблемы Hyperswarm с симметричным NAT/CGNAT. DHT и UDP hole-punching не всегда справляются с жёсткими NAT, характерными для мобильных операторов РФ. Смягчение: приоритет WebSocket-транспорта как основного в проблемных сетях; исследование DCUtR как более надёжной альтернативы.

10. Уязвимость DHT к Sybil-атакам. Hyperswarm (как и любой открытый DHT) не имеет встроенной защиты от наводнения сети подставными узлами. Это создает риск изоляции пользователя или перехвата его запросов. Смягчение: на начальном этапе полагаемся на фиксированные bootstrap-узлы и ретрансляторы; в перспективе — исследование механизмов репутации пиров.

? Часть 6. Дорожная карта: новые задачи

1. Точная имитация TLS (JA3/JA4). Исследовать подмену отпечатка в Bare (C++ модуль) или внешний прокси на Go.

2. WebSocket fallback как основной транспорт. Реализовать режим wss:// на ретранслятор.

3. Поведенческая мимикрия (исследовательская). Адаптация трафика под паттерны пользователя(ML).

4. Автономные бутстрап-узлы в РФ. Поднять серверы на VK Cloud, Яндекс.Облако с HTTPS-прокси.

5. Исследование librats / DCUtR. Создать экспериментальную ветку, сравнить с JS-версией libp2p по CPU и батарее.

6. Интеграция готовых open-source модулей (осторожно, с учётом ограничений Android). Подключить TrustTunnel, AmneziaWG, Zapret, ByeByeDPI как сменные транспорты — но только для десктопной версии или для rooted Android (либо через локальный VPN для ByeByeDPI).

7. Исследование протокола MASQUE. Отслеживать стандартизацию и тестировать реализацию Usque.

8. Использование Nostr как бэкенда. Изучить возможность замены собственной DHT-сети на публичные ретрансляторы Nostr.

9. Защита метаданных через NymVPN (опционально). Маршрутизация через mixnet для максимальной приватности.

? Заключение

Jami показал, что хорошая идея может быть похоронена под устаревшей архитектурой. Keet показал, что открытая платформа может служить основой для P2P-приложений, но его клиент закрыт. Наша задача — взять лучшее от обоих миров: открытую технологию Pear Runtime и требования к устойчивости из первой статьи — и сделать экспериментальный открытый клиент.

Это не «ещё один мессенджер». Это попытка исследовать, какие технологии действительно работают в российских сетях, как повысить стоимость блокировки и сохранить приватность. И теперь у нас есть не только план, но и конкретный набор open-source «кирпичиков», из которых сообщество может собрать рабочий прототип.

Архитектура будущего мессенджера в одной схеме:

[Пользователь Android]
        |
        v
[Foreground Service (работа в фоне)]
        |
        v
[Выбор транспорта в зависимости от сети:]
   - WebSocket over TLS + имитация JA3
   - (внешние инструменты: Zapret/AmneziaWG/ByeByeDPI для обфускации)
        |
        v
[Децентрализованная сеть: Hyperswarm / librats / Nostr]
        |
        v
[Ретрансляция через пиров или публичные релеи]
        |
        v
[Fallback: асинхронная доставка через HTTPS (ретрансляторы на "белых" доменах)]

Финальный тезис:

❗ Будущее P2P — это не протокол. ✅ Это система, которая переживает деградацию.

Присоединяйтесь. Код ждёт.

⚠️ Финальное юридическое предупреждение

Ещё раз: Данный проект носит исключительно исследовательский и образовательный характер. Автор не несёт ответственности за использование разрабатываемого программного обеспечения в целях, противоречащих законодательству конкретной страны. Каждый пользователь обязан самостоятельно оценить законность применения подобных инструментов в своей юрисдикции.