ZionVox — защищённый мессенджер, боты, публичные страницы и устойчивость сети

ZionVox — экосистема приватного общения: мессенджер с шифрованием по умолчанию (E2EE), группы и каналы, публичные страницы, Bot API с визуальным конструктором, P2P-надстройка для устойчивости при деградации сети и корпоративный контур ZionVox Enterprise для полного контроля данных. Проект развивается как полноценный продукт (веб PWA, мобильные клиенты, публичный сайт web-public), а не как «ещё один чат с криптографией в маркетинге.

Два контура развёртывания

ZionVox Cloud — SaaS: быстрый старт, облачный кластер, обновления от команды.
ZionVox Enterprise — on-premise / выделенный VPS: свои серверы, политики, интеграции, stealth-мосты на своих доменах.
В обоих случаях Core (бэкенд и БД) работает постоянно. Режимы сети описывают не «сервер выключен», а доступность прямого маршрута клиента до Core (DNS, TLS, WebSocket). При блокировке primary-домена клиент переключается на резервные транспорты, но обращается к тому же кластеру.

Шифрование и ключи (E2EE)
Содержимое переписки шифруется на устройстве отправителя; на сервер уходит только шифротекст и метаданные доставки. Ключи: Ed25519 / X25519, восстановление через мнемоническую фразу BIP39 с квизом подтверждения при онбординге. Key bundle хранится зашифрованным; разблокировка сессии — отдельный шаг («заблокировать ключи» в сайдбаре чата).

Клиент формирует сообщение и шифрует для получателя(ей).
На Core передаётся ciphertext + IV + служебные поля протокола.
Core сохраняет запись и уведомляет участников (REST + Socket.IO new_message).
Получатель расшифровывает локально; сервер не имеет plaintext.

Публичные страницы и веб-присутствие
Публичная страница — профиль автора в ZionVox и/или веб-страница (модуль web-public, Next.js): уникальный URL, посты, сторис, медиа, закрепления, комментарии с модерацией, реакции, опросы.

Принципы приватности автора
Публичная страница не раскрывает личный телефон, точную геолокацию и прочие PII без явного согласия.
Подписчики общаются через публичный ник / бренд; приватные сообщения автору — с E2EE.
Гибкие уровни раскрытия: аватар, био, ссылки на внешние соцсети настраиваются отдельно.
Контент и монетизация
Посты с форматированием и вложениями; сторис на 24 часа; прямые эфиры и записи.
Платная подписка, платные посты, донаты — без навязанной рекламной модели платформы.
Публичный ключ страницы для верификации подлинности контента.
Публичные группы пересекаются с этой моделью: открытое вступление, discoverability, модерация и политика записи задаются владельцем. Приватные группы остаются внутри E2EE-контура мессенджера.

Боты, Bot API и конструктор
Бот в ZionVox — участник переписки с ограниченными правами, а не «сервер, который видит все чаты». Диалог пользователь ↔ бот по умолчанию E2EE: бот расшифровывает только на своём runner-сервере; Core не получает plaintext.

Bot API (протокол)
У бота есть ID, username (суффикс bot), публичный ключ, токен для HTTP webhook/long polling.
Входящие: update с зашифрованным телом; исходящие: sendMessage, inline-режим, клавиатуры, файлы.
Права запрашиваются при добавлении: отправка, чтение участия, метаданные — без доступа к чужим чатам.
При недоступности маршрута до Core серверные webhooks не доставляются; runner держит durable outbox до восстановления связи.
Визуальный конструктор ботов
В клиенте: служебный раздел «Боты» в сайдбаре → Bot Studio. Конструктор построен на потоках (flows) и блоках с цепочкой выполнения:

Сообщение — текстовый шаг с опциональной задержкой.
Меню — текст + инлайн-кнопки; сценарий ждёт нажатия.
Вопрос (form) — ожидание ответа текстом, запись в переменные сценария.
Отправить файл — по file_id или HTTPS-URL.
Работа с БД — save / find / buffer в таблицах бота.
Ожидание — пауза от 1 с до нескольких суток.
Ссылка (link) — якорь в потоке.
Переход (jump) — условный goto на якорь в том же потоке.
Передача в поток — передача управления в другой flow бота.
Поддерживаются фильтры на блоках, drag-and-drop порядка, локальный черновик и сохранение на сервер. В демо на портфолио конструктор полностью рабочий (создание бота, редактирование потоков, сохранение JSON в БД); исполнение сценария на реальных пользователях — только в полном кластере ZionVox.

Stealth-мосты (резервный вход в кластер)
Stealth-мост — доверенная альтернативная точка входа к тому же Core: отдельный VPS/домен, reverse-proxy, mTLS к кластеру. Мост не заменяет сервер и бесполезен без upstream к Core.

Жизненный цикл моста
Оператор генерирует ключ и CSR; внутренний CA (air-gapped) подписывает сертификат.
POST /control/bridges/register — мост в статусе pending_verification.
Админ подтверждает: pin CA, DNS challenge, health check, опционально 4-eyes.
Статус active → новый подписанный bootstrap-манифест с endpoint моста.
При компрометации — auto-revoke, emergency reissue манифеста (TTL 1 ч).
Клиент получает список мостов через GET /api/bootstrap/endpoints (подпись Ed25519), кэширует assist, при stale TTL до 7 суток может использовать последний подписанный снимок. Push-обновление: Socket.IO bootstrap_manifest_updated.

STUN, TURN, WebRTC и порядок ICE
WebRTC используется для mesh DM (DataChannel), P2P-файлов и (отдельно) SFU групповых звонков. Установление соединения — через ICE: host-кандидаты, srflx через STUN, relay через TURN.

Роли STUN и TURN
STUN — узнать внешний адрес за NAT; достаточно при «мягком» NAT.
TURN — релей трафика при symmetric NAT / корпоративных firewall; требует своего сервера и квот.
Слияние списка ICE-серверов (веб-клиент)
Функция defaultIceServers() собирает итоговый массив в порядке:

Встроенные публичные STUN (Google, Cloudflare) — всегда, если не включён minimal ICE для E2E-тестов.
ICE из assist-кэша — transportManifest.iceServers после успешного подписанного bootstrap.
VITE_WEBRTC_ICE_SERVERS — дополнение при сборке/dev.
Записи дедуплицируются по ключу urls + username + credential. TURN «из коробки» не раздаётся всем — оператор задаёт его в transport manifest кластера. Групповые звонки mediasoup используют отдельный ICE_SERVERS_JSON на бэкенде SFU.

Порядок переговоров ICE (упрощённо)
Создание RTCPeerConnection с объединённым списком серверов.
Сбор кандидатов: host → srflx (STUN) → relay (TURN) — trickle ICE через сигналинг.
Пара выбирается по приоритету; при fail — следующая пара / ICE restart.
Для mesh DM сигналинг идёт через Core или mesh-транспорт; TURN из bootstrap критичен при жёстком NAT.
Mesh DM, relay, DHT и доставка без прямого API
Когда REST/WebSocket к Core недоступны, но контакты уже «сопряжены», включается mesh data plane: P2P DataChannel, store-and-forward relay_queue, merge по векторным часам / meshDmSeq.

Relay — очередь до 50 MiB, piece ≤256 KiB, uplink 150 MB/день; drain при появлении сокета.
DHT — подписанные маршруты от Core; клиент кэширует с TTL; write отключается в BYPASS/SAFE_MODE.
libp2p / L2 assist — опциональный браузерный DHT-стек для stealth и bootstrap assist.
Multi-device — на серверном sync LWW по editedAt → deviceId → seq, отдельно от mesh VC.
Re-entry, кворумы и работа без прямой связи с сервером
Сценарий peer-validated re-entry: пользователь потерял прямой доступ к Core, но может доказать идентичность через сеть доверенных валидаторов.

Служебные разделы интерфейса чата
Заметки — локальный чат с собой, только на устройстве.
Поддержка — чат с операторами (серверный, не E2EE).
Боты — Bot Studio и токены API.
Плеер — глобальный аудио/видео плеер.
Вкладки сайдбара: Контакты, Чаты, Спам; кнопки профиля, настроек, блокировки ключей.
Технологический стек
Frontend: React, TypeScript, Vite, Redux Toolkit, Web Crypto API, IndexedDB, PWA.
Backend: Node.js, Express, PostgreSQL, Redis, Socket.io, mediasoup.
Mobile: Expo / React Native.
Пакеты: zionvox-p2p-protocol, zionvox-api-contract.
Криптография: Ed25519, X25519, BIP39, зашифрованные key bundle.