Konstruct

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 is built on cryptographic principles we treat as invariant: Конструкт построен на криптографических принципах, которые мы считаем инвариантными:

1. No safe backdoors. Any intentional weakening of encryption — regardless of pretext — creates a vulnerability that will be exploited by adversaries. E2EE must be absolute and verifiable. 1. Безопасных бэкдоров не существует. Любое намеренное ослабление шифрования — независимо от предлога — создаёт уязвимость, которая будет использована противником. Сквозное шифрование должно быть абсолютным и проверяемым.

2. Privacy-by-default. The system must protect confidentiality without requiring user action or justification. Privacy is a property of the protocol, not a setting. 2. Приватность по умолчанию. Система обязана защищать конфиденциальность без действий со стороны пользователя. Приватность — свойство протокола, а не настройка.

3. Server-blind architecture. The server must be technically incapable of reading content, resolving group membership, or exposing decryptable metadata. Trusting the operator is not a substitute for cryptographic guarantees. 3. Server-blind архитектура. Сервер не должен иметь технической возможности читать контент, определять состав групп или раскрывать расшифруемые метаданные. Доверие к оператору — не замена криптографическим гарантиям.

4. Decentralisation by design. Centralised platforms present a single point of legal and technical pressure. Federated and P2P topologies distribute trust and eliminate censurability at the protocol level. 4. Децентрализация в дизайне. Централизованные платформы — единая точка юридического и технического давления. Федеративные и P2P-топологии распределяют доверие и устраняют подверженность цензуре на уровне протокола.

5. Post-quantum readiness. "Capture now, decrypt later" is an active threat model. Hybrid post-quantum key exchange must be integrated today to protect data against future cryptanalytic breakthroughs. 5. Постквантовая готовность. «Перехвати сейчас — расшифруй потом» — актуальная модель угрозы. Гибридный постквантовый обмен ключами должен быть встроен сегодня для защиты данных от будущих криптоаналитических прорывов.

Konstruct implements these principles using 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 uses always-on sealed sender (Stealth) for eligible traffic — the server does not see who sent a message, only the recipient, arrival time, and size (honest limits: timing/IP still visible on the wire). 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. Минимизация метаданных со стороны отправителя — через always-on sealed sender (Stealth) для подходящего трафика: сервер не видит, кто отправил, только получателя, время прибытия и размер (честные пределы: timing/IP на проводе всё ещё видны). Будущий релиз также поддержит прямую 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 framing, and keeps a persistent bidirectional MessageStream open for real-time delivery — not request/response polling. The backend is split into independent microservices (auth, user, messaging, signaling, media) for fault isolation. Most consumer messengers still ship REST/JSON or proprietary TCP stacks; Konstruct’s live path is gRPC bidi over QUIC, with HTTP/2 as automatic fallback. Конструкт использует gRPC с Protocol Buffers для эффективной бинарной передачи и держит постоянный двунаправленный MessageStream для доставки в реальном времени — без polling. Бэкенд разделён на независимые микросервисы (auth, user, messaging, signaling, media) для изоляции отказов. Большинство потребительских мессенджеров всё ещё сидят на REST/JSON или проприетарном TCP; боевой путь Конструкта — gRPC bidi поверх QUIC, с автоматическим fallback на HTTP/2.

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. Hybrid ML-DSA-65 (Dilithium-3, NIST FIPS 204) signing and verification are implemented and cross-verified between client and server; client-side key rotation orchestration is still in progress. Подписи: 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 delivery timestamps and recipient for routing. Eligible user traffic uses always-on sealed sender (Stealth) so the envelope omits the sender id — only the recipient can unseal who wrote. Privacy Pass anti-spam tokens can accompany sealed sends; server-side token enforcement is still rolling out. Сервер не видит содержимого: сообщения хранятся только в виде шифротекста; сервер не может расшифровать. Для маршрутизации сервер видит время доставки и получателя. Подходящий пользовательский трафик идёт с always-on sealed sender (Stealth) — в конверте нет id отправителя, только получатель может раскрыть, кто написал. Токены Privacy Pass могут сопровождать sealed-отправки; server-side enforcement токенов ещё раскатывается.
• Crypto Agility: versioned protocol suites allow algorithm upgrades without rebuilding client apps. Крипто-эластичность: версионированные крипто-suite позволяют обновлять алгоритмы без пересборки клиентских приложений.

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

• gRPC bidirectional MessageStream over QUIC — live production path on iOS (ConstructEngine / construct-transport). One long-lived stream carries heartbeats, inbound messages, and delivery receipts without opening a new TCP handshake per event. QUIC brings connection migration, multiplexed streams, and faster recovery on lossy or long-haul links (validated intercontinentally, e.g. Australia → EU edge). Двунаправленный gRPC MessageStream поверх QUIC — боевой путь на iOS (ConstructEngine / construct-transport). Один долгоживущий поток несёт heartbeat’ы, входящие сообщения и receipt’ы без нового TCP-handshake на каждое событие. QUIC даёт migration соединения, мультиплексирование и быстрое восстановление на нестабильных и дальних линках (проверено на межконтинентальных связях, напр. Австралия → EU edge).
• gRPC over HTTP/2 (TLS 1.3): automatic fallback when QUIC is blocked or handshakes time out — same protobuf contracts, same E2EE payload, no user toggle. gRPC поверх HTTP/2 (TLS 1.3): автоматический fallback, если QUIC режется или handshake не успевает — те же protobuf-контракты и E2EE-полезная нагрузка, без пользовательского переключателя.
• Why this is a product edge: mainstream privacy messengers still lean on REST/JSON (Signal-class stacks) or closed proprietary wire formats (WhatsApp, Telegram MTProto). Shipping a modern gRPC bidi + QUIC live path is rare in consumer messaging — lower framing overhead, fewer reconnect storms, and a stack that matches how high-performance services are built today. E2EE stays on top; transport only moves sealed ciphertext. Почему это преимущество: массовые приватные мессенджеры по-прежнему опираются на REST/JSON (класс Signal) или закрытые wire-форматы (WhatsApp, Telegram MTProto). Боевой путь gRPC bidi + QUIC в consumer-мессенджере — редкость: меньше overhead на кадрирование, меньше reconnect-штормов, стек как у high-performance сервисов. E2EE остаётся сверху; транспорт двигает только sealed ciphertext.
• 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. Дзен-интерфейс — никакого спама уведомлений, никакого социального шума, только спокойное общение.
• Modern live transport — gRPC bidirectional MessageStream over QUIC (HTTP/2 fallback), VEIL when the path is censored, direct P2P planned when both peers are online. Современный live-транспорт — двунаправленный gRPC MessageStream поверх QUIC (fallback HTTP/2), VEIL при цензуре, прямой P2P — в плане, когда оба peer’а онлайн.

No Telemetry. Not Anonymised — Absent.Никакой телеметрии. Не «обезличенной» — её просто нет.

Konstruct collects no analytics, no usage metrics, no behavioural events, no crash phone-home and no advertising identifiers. Not "collected and anonymised" — not collected. This is possible because we are not funded by advertising or data resale, so there is no reason to watch you, and the app is built so we can't. Konstruct не собирает никакой аналитики, метрик использования, поведенческих событий, отправки крашей и рекламных идентификаторов. Не «собрано и обезличено» — не собрано вовсе. Это возможно потому, что мы не живём на рекламе или перепродаже данных — а значит, нет причин за тобой следить, и приложение построено так, что мы не можем.

• No third-party SDKs. No Firebase, Crashlytics, Sentry, Amplitude, Segment — no tracker of any kind. The app's only external dependencies are transport and media infrastructure (gRPC, WebRTC) and an on-device ML library. No ATT prompt, no SKAdNetwork. Никаких сторонних SDK. Ни Firebase, ни Crashlytics, ни Sentry, ни Amplitude, ни Segment — вообще никаких трекеров. Единственные внешние зависимости — транспорт и медиа (gRPC, WebRTC) и on-device ML-библиотека. Без ATT-запроса, без SKAdNetwork.
• Production keeps no logs. Release builds write no diagnostic log to disk and expose no debug or log-export surface. When we need logs to fix a bug, it is you who taps "share" in a beta build — never a silent background upload. В проде нет логов. Релизные сборки не пишут диагностических логов на диск и не дают доступа к дебагу или экспорту логов. Когда нам нужны логи для починки бага, их отправляешь ты кнопкой «поделиться» в бета-сборке — никакой тихой фоновой отправки.
• Honest about what the server must see. To route ciphertext the server necessarily holds a small, fixed set of metadata (recipient, timing, size, your public keys, push token) — always-on sealed sender removes even who sent a message from the stored envelope. What we don't yet fully solve (timing/IP correlation) lives in our Privacy Policy, not in a marketing promise. Честно о том, что видит сервер. Чтобы маршрутизировать шифротекст, сервер вынужденно хранит небольшой фиксированный набор метаданных (получатель, время, размер, твои публичные ключи, push-токен) — always-on sealed sender убирает из хранимого конверта даже то, кто отправил сообщение. Что мы пока не решаем полностью (корреляция timing/IP) — описано в Политике конфиденциальности, а не в маркетинге.

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

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 · live gRPC bidi MessageStream over QUIC (HTTP/2 fallback; intercontinental production validation) · 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 · always-on Stealth (sealed sender) for eligible traffic. Сделано (H1 2026): gRPC/Protobuf · боевой gRPC bidi MessageStream поверх QUIC (fallback HTTP/2; межконтинентальная production-валидация) · X3DH + Double Ratchet · гибридный PQXDH с ML-KEM-768 (opt-in) · session healing · WebRTC голос/видео с E2EE-сигналингом · iOS TestFlight бета · always-on Stealth (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 · hybrid PQ signatures (ML-DSA-65) — crypto core and server storage /verification implemented, client-side orchestration (identity generation, key rotation) not yet wired into the shared core. В работе: публичная раскатка тикетов veil-front · macOS Desktop-клиент (iOS-direct крипто-путь, публичной сборки пока нет) · Android-клиент (сейчас Phase 0 — Rust core собирается, Kotlin-обёртка в работе) · BIP39 / SLIP-39 социальное восстановление · MLS групповые чаты (RFC 9420) · первый внешний security-аудит · гибридные PQ-подписи (ML-DSA-65) — crypto core и серверное хранение/верификация реализованы, оркестрация на клиенте (генерация identity, ротация ключей) в общем ядре ещё не реализована.

Decentralization RoadmapДорожная карта децентрализации

• Phase 1 — Core Relay (H2 2026): standalone construct-relay binary deployable on a \$5 VPS or Raspberry Pi · single Docker container, no Kafka/Redis/PostgreSQL required · preserves all E2EE guarantees · federation gateway for backward compatibility. Фаза 1 — Core Relay (H2 2026): отдельный бинарник construct-relay, запускаемый на \$5 VPS или Raspberry Pi · один Docker-контейнер без Kafka/Redis/PostgreSQL · все E2EE-гарантии сохранены · федеративный шлюз для обратной совместимости.
• Phase 2 — DHT & Discovery (2027): Kademlia DHT overlay for peer discovery and responsible-node routing · signed user records in DHT · offline message storage with replication · bootstrap node network. Фаза 2 — DHT и Discovery (2027): оверлей Kademlia DHT для поиска узлов и маршрутизации · подписанные записи пользователей в DHT · хранение оффлайн-сообщений с репликацией · сеть bootstrap-нод.
• Phase 3 — Hybrid Routing & P2P (2027): direct peer-to-peer delivery via libp2p hole-punching · automatic fallback to relay routing · online presence in DHT · client multi-relay support. Фаза 3 — Гибридный роутинг и P2P (2027): прямая P2P-доставка через libp2p hole-punching · автоматический fallback на релейный роутинг · онлайн-присутствие в DHT · поддержка нескольких релеев на клиенте.
• Phase 4 — Ecosystem (2027–2028): public seed nodes · spam resistance (RLN / proof-of-work) · MLS group chats over decentralised transport · reputation for relay operators · external security audit. Фаза 4 — Экосистема (2027–2028): публичные seed-ноды · защита от спама (RLN / proof-of-work) · групповые MLS-чаты поверх децентрализованного транспорта · репутация операторов релеев · внешний security-аудит.

Other Planned WorkПрочие планы

• Privacy Pass token enforcement (anti-spam on the always-on sealed-sender path) · desktop applications for Windows, Linux · formal verification (Kani). Enforcement Privacy Pass токенов (анти-спам на always-on sealed-sender пути) · десктоп-приложения для Windows, Linux · формальная верификация (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 weak-copyleft licenses: MPL-2.0 for the client apps and VEIL, AGPL-3.0 for the server and relay, Apache-2.0 for shared libraries, and CC-BY-4.0 for text / specs. Privacy technology should be transparent and auditable by anyone — including the open issues we haven't fixed yet. Конструкт открыт под weak-copyleft лицензиями: MPL-2.0 для клиентских приложений и VEIL, AGPL-3.0 для сервера и релея, Apache-2.0 для общих библиотек и 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 читают живые люди, а не фильтрует очередь.

• GitHubGitHub
• Protocol specification & whitepaperСпецификация протокола и whitepaper
• iOS TestFlight Public AlphaiOS TestFlight Public Alpha
• Report a security issue (GitHub private advisory)Сообщить о security-проблеме (приватный advisory на GitHub)

Support the ProjectПоддержать проект

No ads, no data resale, no telemetry — Konstruct runs on voluntary donations. If you want the messaging core to stay free and independent, a donation directly funds development and the server. Prefer Monero if you value privacy: unlike Bitcoin, its chain is not public, so your donation isn't linkable and the balance isn't visible. Без рекламы, без перепродажи данных, без телеметрии — Konstruct живёт на добровольных донатах. Если хочешь, чтобы ядро мессенджера оставалось бесплатным и независимым, донат напрямую идёт на разработку и сервер. Если ценишь приватность — предпочти Monero: в отличие от биткоина его цепочка не публична, донат нельзя связать, а баланс не виден.

Security tip: these addresses are also published, PGP-signed, in the project repository — cross-check them there before sending, in case this page is ever tampered with. Signing key fingerprint: Совет по безопасности: эти адреса также опубликованы и PGP-подписаны в репозитории проекта — сверь их там перед отправкой на случай, если эту страницу подменят. Отпечаток ключа подписи: 13AC BE18 0D7B 20A2 4D2D D6B0 99DD 3ECE 736F 0672