|

Konstruct

Privacy is a fundamental human right, not a luxury feature. Konstruct is an open-source encrypted messenger built on the Signal Protocol design (X3DH + Double Ratchet) with a hybrid post-quantum key exchange (ML-KEM-768). The internet must remain a free space for information exchange, without ideological censorship or mass surveillance. Приватность — фундаментальное право человека, а не платная функция. Конструкт — криптостойкий мессенджер с открытым исходным кодом, построенный на проверенном шифровании Signal Protocol с постквантовой защитой. Интернет должен оставаться свободным пространством для обмена информацией — без идеологической цензуры и массовой слежки.

End-to-End EncryptedСквозное шифрование Post-Quantum KEMПостквантовый KEM Federated (Planned)Федерация (план) P2P (Planned)P2P (план) Server-Blind ContentСервер без доступа к контенту Open SourceОткрытый исходный код

Our MissionНаша миссия

Privacy and security are not optional. In an era of mass surveillance, data breaches, and emerging quantum computing threats, communication privacy is more critical than ever. Приватность и безопасность — не опции. В эпоху массовой слежки, утечек и сбора данных, а так же угроз квантовых вычислений конфиденциальность коммуникаций становится важнее чем когда-либо.

Konstruct uses the Signal Protocol design (X3DH handshake + Double Ratchet) — the same end-to-end encryption design that powers Signal and WhatsApp — implemented from scratch in Rust. We extend it with a hybrid post-quantum KEM (ML-KEM-768, NIST FIPS 203) so that traffic recorded today remains protected once cryptographically relevant quantum computers exist. Конструкт использует Signal Protocol (X3DH + Double Ratchet) — тот же дизайн сквозного шифрования, что применяют Signal и WhatsApp — с собственной реализацией на Rust. Расширен гибридным постквантовым KEM (ML-KEM-768, NIST FIPS 203), чтобы трафик, записанный сегодня, оставался защищённым после появления криптографически значимых квантовых компьютеров.

Unlike centralized platforms, Konstruct is designed for federation — eventually you will be able to choose or run your own server (you@your-server.example). The server is blind to message content: it stores only public keys and encrypted ciphertext, never plaintext. Sender-side metadata minimisation (sealed sender) already exists as an opt-in Stealth Mode — off by default. A future release will also support direct peer-to-peer delivery when both parties are online, removing the server from the data path entirely. Federation and P2P are part of the 2027 roadmap; today the network is a single trusted server. В отличие от централизованных платформ, Конструкт спроектирован под федерацию — в будущем вы сможете выбрать или запустить собственный сервер (you@your-server.example). Сервер не видит содержимого сообщений: хранит только публичные ключи и минимальное количество метаданных, врде username или состава групп в виде необратимого хэша, никогда не plaintext. Минимизация метаданных со стороны отправителя (sealed sender) уже существует как opt-in Stealth Mode — выключен по умолчанию. Будущий релиз также поддержит прямую P2P-доставку, когда оба собеседника онлайн, убирая сервер из пути данных. Федерация и P2P — часть дорожной карты на 2027 год; сегодня сеть — один доверенный сервер.

The internet must remain free. No government, corporation, or algorithm should control what you can say or who you can talk to. Konstruct is built to protect that freedom. Интернет должен оставаться свободным. Ни правительство, ни корпорация, ни алгоритм не должны контролировать что ты говоришь и с кем общаешься. Конструкт создан чтобы защитить эту свободу.

Technical ArchitectureТехническая архитектура

Konstruct uses gRPC with Protocol Buffers for efficient binary message framing, and is split into independent microservices on the server side (auth, user, messaging, signaling, media) for fault isolation. Reproducible benchmarks comparing bandwidth and latency against JSON-based messengers are part of upcoming work, not yet published. Конструкт использует gRPC с Protocol Buffers для эффективной бинарной передачи сообщений, а бэкенд разделён на независимые микросервисы для изоляции отказов. Воспроизводимые бенчмарки и задержки по сравнению с JSON-мессенджерами — часть будущей работы, пока не опубликованы.

Cryptography StackСтек криптографии

  • X3DH + Double Ratchet (Signal Protocol design): end-to-end encryption with forward secrecy and post-compromise security (self-healing). X3DH + Double Ratchet (дизайн Signal Protocol): сквозное шифрование с прямой секретностью и post-compromise security (самовосстановление).
  • Hybrid Post-Quantum KEM: X25519 classical + ML-KEM-768 (NIST FIPS 203, Kyber-768) for key exchange. If either component is broken, the other still protects. Гибридный постквантовый KEM: классический X25519 + ML-KEM-768 (NIST FIPS 203, Kyber-768) для обмена ключами. Если одна из компонент скомпрометирована, вторая продолжает защищать.
  • Authentication signatures: Ed25519 today. ML-DSA-65 (Dilithium-3, NIST FIPS 204) is planned for hybrid signatures — not yet implemented. Подписи: Ed25519 сегодня. ML-DSA-65 (Dilithium-3, NIST FIPS 204) запланирован для гибридных подписей — пока не реализован.
  • AEAD: ChaCha20-Poly1305 for message encryption. KDF: HKDF-SHA256 with domain-separation labels per protocol section. Anti-spam PoW: Argon2id. AEAD: ChaCha20-Poly1305 для шифрования сообщений. KDF: HKDF-SHA256 с метками domain-separation для каждой секции протокола. Anti-spam PoW: Argon2id.
  • Server is blind to content: messages are stored only as ciphertext; the server cannot decrypt. By default the server still sees routing metadata (sender identifier, delivery timestamps). Sender-side metadata minimisation (sealed sender) is implemented as an opt-in Stealth Mode — off by default; the optional Privacy Pass anti-spam token layer on top of it is not yet server-enforced. Сервер не видит содержимого: сообщения хранятся только в виде шифротекста; сервер не может расшифровать. По умолчанию сервер всё ещё видит маршрутные метаданные (идентификатор отправителя, временные метки доставки). Минимизация метаданных со стороны отправителя (sealed sender) реализована как opt-in Stealth Mode — выключен по умолчанию; опциональный слой анти-спам токенов Privacy Pass над ним пока не требуется сервером.
  • Crypto Agility: versioned protocol suites allow algorithm upgrades without rebuilding client apps. Крипто-эластичность: версионированные крипто-suite позволяют обновлять алгоритмы без пересборки клиентских приложений.

Transport LayerТранспортный уровень

  • gRPC over HTTP/2: primary message transport — persistent bidirectional stream with server push. gRPC поверх HTTP/2: основной транспорт сообщений — постоянный двунаправленный поток с server push.
  • QUIC engine (ConstructEngine): secondary transport with 0-RTT resumption and multiplexed streams for lossy networks. Currently disabled on iOS pending upstream fixes; macOS/desktop rollout is paused while the desktop client moves to the same direct crypto path as iOS — not in the live transport path on any platform today. QUIC-движок (ConstructEngine): вторичный транспорт с 0-RTT и мультиплексированием потоков для нестабильных сетей. На iOS сейчас отключён до апстрим-фиксов; раскатка на macOS/десктоп приостановлена, пока десктоп-клиент переходит на тот же direct-крипто-путь, что и iOS — сегодня не задействован в боевом транспорте ни на одной платформе.
  • VEIL (anti-censorship): traffic obfuscation when direct TLS is throttled or blocked. Today: obfs4 + WebTunnel pluggable transports, currently throttled by active DPI in some regions. veil-front, an honest-front HTTPS layer that makes tunnelled traffic indistinguishable from a real public web service, is implemented and validated on real devices with provisioned tickets; public rollout is in progress. VEIL (защита от цензуры): обфускация трафика когда прямой TLS режется или блокируется. Сегодня: obfs4 + WebTunnel pluggable transports, сейчас режутся активным DPI в ряде регионов. veil-front — honest-front HTTPS слой, который делает туннельный трафик неотличимым от настоящего публичного web-сервиса — реализован и провалидирован на реальных устройствах с выданными тикетами; публичная раскатка в процессе.

Key FeaturesКлючевые возможности

  • End-to-end encryption by default — servers see only encrypted blobs. Сквозное шифрование по умолчанию — серверы видят только зашифрованные данные.
  • Forward secrecy — past messages stay secure even if keys leak. Прямая секретность — прошлые сообщения остаются защищёнными даже при компрометации ключей.
  • Post-quantum key exchange — hybrid X25519 + ML-KEM-768 (Kyber-768). Signatures are Ed25519 today; ML-DSA-65 (Dilithium-3) for hybrid signatures is planned. Постквантовый обмен ключами — гибрид X25519 + ML-KEM-768 (Kyber-768). Подписи сейчас Ed25519; ML-DSA-65 (Dilithium-3) для гибридных подписей — в планах.
  • Federation — run your own server or use a trusted provider, with email-like addressing. Федерация — собственный сервер или доверенный провайдер с email-подобной адресацией.
  • Lightweight server — Rust-based, minimal resource use, easy self-hosting. Лёгкий сервер — на Rust, минимальное потребление ресурсов, простой самостоятельный хостинг.
  • Zen UI — no notification spam, no social noise, focus on calm interaction. Дзен-интерфейс — никакого спама уведомлений, никакого социального шума, только спокойное общение.
  • Resilient delivery — gRPC/HTTP2 primary, QUIC engine secondary, VEIL relay fallback, direct P2P when both are online. Устойчивая доставка — gRPC/HTTP2 основной путь, QUIC движок резервный, VEIL relay запасной, прямой P2P когда оба онлайн.

Industry ComparisonСравнение с другими

PlatformПлатформа FederatedФедеративный E2EE DefaultE2EE по умолч. Post-QuantumПостквантовый P2P ModeP2P-режим ProtocolПротокол Open SourceОткрытый код
Signal No Yes Yes (PQXDH) No REST/JSON Yes
WhatsApp No Yes No No Proprietary No
Telegram No No* No No MTProto Partial
Matrix Yes Optional Planned No HTTP/JSON Yes
Session† Decentralised Yes No Onion Proprietary Yes
Konstruct Planned Yes KEM (opt-in) Planned gRPC+QUIC Yes

* Telegram E2EE only in "Secret Chats", not default.
† Session V1 protocol uses static long-term keys — no forward secrecy or PCS.
‡ Konstruct's PQ KEM (ML-KEM-768) is opt-in and deployed; PQ signatures (ML-DSA-65) are planned, not yet implemented.
* E2EE в Telegram только в «Секретных чатах», не по умолчанию.
† Session V1 использует статические долгосрочные ключи — без forward secrecy и PCS.
‡ Постквантовый KEM Конструкта (ML-KEM-768) — opt-in и развёрнут; постквантовые подписи (ML-DSA-65) запланированы, пока не реализованы.

Designed for Graceful DegradationСпроектировано для плавной деградации

Centralised privacy projects are fragile: when funding dries up or a single operator is compelled to shut down, the network goes with them. Konstruct is designed around the opposite principle — as components disappear, the rest keeps working. The target architecture is three tiers, each with the same end-to-end cryptographic guarantees regardless of delivery path. Today only Tier 1 with a single trusted server is live; Tiers 2 and 3 are on the roadmap. Централизованные privacy-проекты хрупки: когда финансирование заканчивается или единственного оператора заставляют закрыться — сеть исчезает вместе с ним. Конструкт построен по обратному принципу: по мере исчезновения компонентов остальные продолжают работать. Целевая архитектура — три уровня, на каждом сохраняются одни и те же E2E-гарантии независимо от пути доставки. Сегодня работает только Tier 1 с одним доверенным сервером; Tier 2 и 3 — в дорожной карте.

  • Tier 1 — Federated servers (planned 2027): anyone will be able to run a Konstruct server with an email-style address (you@your-server.example). If the founding team disappears, community-operated nodes can keep the network alive. Tier 1 — Федеративные серверы (план: 2027): любой сможет запустить Конструкт-сервер с адресом email-стиля (you@your-server.example). Если основная команда исчезнет, ноды сообщества смогут поддерживать сеть.
  • Tier 2 — Community relay nodes (planned 2027): lightweight relays (designed to run on hardware as small as a Raspberry Pi) will provide message routing without a full server — no user database, no key storage. Tier 2 — Ноды-ретрансляторы сообщества (план: 2027): лёгкие ретрансляторы (рассчитанные на железо уровня Raspberry Pi) будут обеспечивать маршрутизацию сообщений без полноценного сервера — без базы пользователей, без хранения ключей.
  • Tier 3 — Direct P2P (planned 2027+): when both users are online, messages will travel directly between devices over QUIC/ICE — the server steps out of the data path entirely. Tier 3 — Прямой P2P (план: 2027+): когда оба собеседника онлайн, сообщения будут идти напрямую между устройствами по QUIC/ICE — сервер полностью выйдет из пути данных.

The Signal Protocol design (X3DH + Double Ratchet + hybrid PQ KEM) is transport-agnostic: whether messages travel through a server, a relay node, or directly between devices, the cryptographic guarantees stay the same. Дизайн Signal Protocol (X3DH + Double Ratchet + гибридный PQ KEM) не зависит от транспорта: идут ли сообщения через сервер, ретранслятор или напрямую между устройствами — криптографические гарантии остаются теми же.

Development RoadmapДорожная карта

  • Done (H1 2026): gRPC/Protobuf transport · X3DH + Double Ratchet · hybrid PQXDH with ML-KEM-768 (opt-in) · session healing · WebRTC voice/video calls with E2EE signaling · iOS TestFlight beta · VEIL anti-censorship (obfs4, WebTunnel) · veil-front implemented and validated on-device · Stealth Mode (opt-in sealed sender). Сделано (H1 2026): транспорт gRPC/Protobuf · X3DH + Double Ratchet · гибридный PQXDH с ML-KEM-768 (opt-in) · session healing · WebRTC голос/видео с E2EE-сигналингом · iOS TestFlight бета · Stealth Mode (opt-in sealed sender) · VEIL anti-censorship (obfs4, WebTunnel) · veil-front реализован и провалидирован на устройстве.
  • In progress: veil-front public ticket rollout · macOS Desktop client (iOS-direct crypto path, no public build yet) · Android client (currently Phase 0 — Rust core builds, Kotlin wrapper TBD) · BIP39 / SLIP-39 social recovery · MLS group chats (RFC 9420) · first external security audit. В работе: публичная раскатка тикетов veil-front · macOS Desktop-клиент (iOS-direct крипто-путь, публичной сборки пока нет) · Android-клиент (сейчас Phase 0 — Rust core собирается, Kotlin-обёртка в работе) · BIP39 / SLIP-39 социальное восстановление · MLS групповые чаты (RFC 9420) · первый внешний security-аудит.
  • Planned (2026 H2 – 2027): Privacy Pass token enforcement (anti-spam for Stealth Mode) · desktop applications for Windows, Linux · federation protocol · community relay nodes · direct P2P delivery · hybrid PQ signatures (ML-DSA-65) · formal verification (Kani). Планы (H2 2026 – 2027): enforcement Privacy Pass токенов (анти-спам для Stealth Mode) · десктоп-приложения для Windows, Linux · протокол федерации · community relay-ноды · прямая P2P-доставка · гибридные постквантовые подписи (ML-DSA-65) · формальная верификация (Kani).

Honest current status: alpha. iOS via TestFlight only (join the beta); no public App Store release yet. macOS Desktop client is in active development, no build available yet. Single trusted server (no federation). VEIL obfs4 transport is deployed but currently throttled by active DPI in some regions; the veil-front replacement is implemented and validated on-device, with public ticket rollout in progress. Not recommended for adversarial threat models until first external audit completes. Честный текущий статус: alpha. iOS только через TestFlight (присоединиться к бете); публичного релиза в App Store пока нет. macOS Desktop-клиент в активной разработке, сборки пока нет. Один доверенный сервер (без федерации). VEIL obfs4-транспорт развёрнут, но сейчас режется активным DPI в ряде регионов; замена veil-front реализована и провалидирована на устройстве, публичная раскатка тикетов в процессе. Не рекомендуется для adversarial-угроз до завершения первого внешнего аудита.

Open Source & Contributions Открытый исходный код и участие

Konstruct is open-source under the MIT License (code) and CC-BY-4.0 (text / specs). Privacy technology should be transparent and auditable by anyone — including the open issues we haven't fixed yet. Конструкт открыт под лицензией MIT (код) и CC-BY-4.0 (тексты / спецификации). Технологии приватности должны быть прозрачными и доступными для аудита любым желающим — включая открытые проблемы, которые мы пока не исправили.

Contributions welcome — from code improvements to security review to documentation. We are a tiny team; PRs and issues are read by humans, not triaged by a queue. Контрибьюторы приветствуются — от улучшений кода до review безопасности и документации. Команда крошечная: PR и issues читают живые люди, а не фильтрует очередь.