The short version

An account is a keypair. No phone number, no email, no required username, and discovery is off by default. A request to a carrier gets nothing, because no carrier is in the loop.

gRPC bidirectional — over QUIC with HTTP/2 fallback on iOS, over HTTP/2 on Android — one long-lived stream that survives a change of network without a new handshake.

Post-quantum, already in the protocol. ML-KEM-1024 is encapsulated to the recipient's Kyber prekey at session setup (PQXDH) and goes into the session's initial key. The first message of a conversation is protected too, and a session is not established at all without the post-quantum part. This protects what messages and attachments say. Who sent a message is protected post-quantum too, and calls are when both apps offer post-quantum DTLS. Still classical: the server's signatures (sender certificates, key-transparency heads), device sign-in and account recovery; groups do not exist yet — the protocol specification lists every layer.

The sender is not in the envelope. Sealed sender* is unconditional for ordinary traffic. To route a message the server has an opaque account id**, a size and a time.

  • * Sealed sender means a message travels with no mark of who wrote it. Only the recipient can open that; the server cannot. In the app it is always on (shown as “stealth” under Security); there is nothing to switch.
  • ** An opaque identifier is a string that says nothing about you — characters assigned when the account was created.

What exists today

Konstruct currently exists as a second communications channel alongside your primary one. Its feature set is minimal — one-to-one chats and calls. No groups, channels, or sync between devices.

Technical Architecture

The short version: messages are encrypted on your device. The server carries ciphertext without being able to read it; this section explains the layers underneath.

Konstruct is built on the Signal Protocol design (X3DH + Double Ratchet), written from scratch in Rust and extended with post-quantum key agreement (ML-KEM-1024).

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 services (identity, messaging, signaling, media) for fault isolation. On iOS the live path is gRPC bidi over QUIC, with HTTP/2 as automatic fallback; Android uses HTTP/2.

Cryptography Stack

  • X3DH + Double Ratchet (Signal Protocol design): end-to-end encryption with forward secrecy and post-compromise security (self-healing).
  • Post-quantum key agreement (PQXDH): when a session is established the initiator encapsulates an ML-KEM-1024 secret (NIST FIPS 203) to the recipient's Kyber prekey, and that secret goes into the session's initial key alongside the X25519 outputs, so a recorded session is not recoverable by breaking X25519 alone. Post-quantum protection covers the very first message, and there is no classical way to establish a session. On top of that, every session runs a sparse ML-KEM-768 ratchet — fresh post-quantum material is mixed in as the conversation goes (every 16 turns or every 7 days), not once at setup, and each message gets its own post-quantum key derived from it.
  • Signatures: hybrid Ed25519 + ML-DSA-65 (Dilithium-3, NIST FIPS 204) on every post-quantum prekey — both must verify: the client refuses a prekey without both. The hybrid key itself is vouched for by Ed25519 and pinned on first contact. Device sign-in, account recovery and the server's sender certificates are still Ed25519 only.
  • AEAD: ChaCha20-Poly1305 for message encryption. KDF: HKDF-SHA256 with domain-separation labels per protocol section. Anti-spam PoW: Argon2id.
  • Server is blind to content: messages are stored only as ciphertext and cannot be decrypted by the server. Privacy Pass anti-spam tokens can accompany sealed sends; server-side token enforcement is still rolling out.
  • Crypto agility: the protocol carries a suite version, so a new algorithm set can be introduced without changing the message format. The recent migrations (PQXDH v2, ratchet suite 4) were hard cutovers: sessions on the old suite are refused and reopen on the next send. While this is an alpha, we choose that over long compatibility windows.

Transport Layer

  • gRPC bidirectional MessageStream over QUIC — the production path on iOS (construct-transport). One long-lived stream carries heartbeats, inbound messages and receipts without a TCP handshake per event, survives a change of network, and falls back to gRPC over HTTP/2 + TLS 1.3 automatically when QUIC is blocked. E2EE sits above it: the transport moves sealed ciphertext only, so changing it changes nothing about the guarantees.
  • Censorship resistance: when a direct TLS connection is blocked, the client routes through an obfuscation layer instead, automatically and with no user action. The implementation is open source and the design is public. Operational detail — which transports are live, which entry points exist and where — is not published, and neither the app nor this site displays it.

What the server sees

Every centralised platform starts from one assumption: “you” are a row in its database. A phone number, a profile, a contact graph that belongs to it and that it can hand over. Konstruct starts from less. The server holds an account identifier, your public keys and a push token. About the message itself it sees only an opaque recipient id, delivery time and size; sealed sender removes the sender id, so only the recipient can reveal who wrote it. That is the minimum routing ciphertext requires.

With no address book there are no cold messages: a conversation starts from a QR code or an invite link — single-use and alive for twelve hours. Search by username exists, is optional, and is off until you turn it on.

Cryptography cannot make you unobservable. Timing and IP correlation remain visible on the wire, and a sufficiently resourced adversary works at that layer, not this one. Even so, no component of our system is designed to accumulate your data.

No Telemetry. Not Anonymised — Absent.

Konstruct collects no analytics, no usage metrics, no behavioural events, no crash reports and no advertising identifiers. There are no third-party SDKs — no Firebase, no Crashlytics, no Sentry — and no ATT prompt or SKAdNetwork. Release builds write no logs. One thing we do not control: while the beta runs on TestFlight, Apple reports its own standard testing metrics to us — install date, build version, session and crash counts. That is Apple's, not ours, and it ends with the App Store release. To route a message the server does hold a small fixed set of metadata — recipient, time, size, your public keys, a push token on iOS — and sealed sender takes the sender out of the envelope as well. What that does not solve, timing and IP correlation, is written down in the Privacy Policy.

Key Features

  • End-to-end encryption by default — servers see only encrypted blobs.
  • Forward secrecy — past messages stay secure even if keys leak.
  • Censorship protection — on by default. Direct while that works, switching only when it demonstrably stops.
  • Zen UI — no notification spam, no social noise, focus on calm interaction.
  • Post-quantum key agreement — ML-KEM-1024 (Kyber-1024) is encapsulated to the recipient's Kyber prekey at session setup (PQXDH) and goes into the initial key; no session is established without it. Every session then keeps re-keying inside the Double Ratchet with ML-KEM-768, and each message gets its own post-quantum key. Signatures are hybrid Ed25519 + ML-DSA-65 (Dilithium-3): every post-quantum prekey carries both, and a session is not established to a prekey without them.
  • Modern live transport — gRPC bidirectional MessageStream over QUIC (HTTP/2 fallback), censorship-resistant routing when the direct path is blocked, direct P2P planned when both peers are online.
  • Open source — clients, server and transport, under weak-copyleft licences. Running your own server is on the roadmap; the app cannot yet be pointed at one.

Design principles

Two positions we do not trade away:

1. There is no safe backdoor. Any deliberate weakening of encryption creates a loophole, and whoever slips through it is not the one it was left for.

2. Privacy by default. It has to hold without the user doing anything: a property of the protocol, not a setting.

What we will not build. No backdoor, whatever the pretext. No engagement mechanics — no infinite scroll, no streaks, no notification bait. No data resale: there is nothing to sell and no advertising business to feed.

Specification and source

Everything on this page is worked through in full in the protocol specification — the whitepaper. It is versioned alongside the code and carries only what can be checked against the reference implementation.

NB: there has been no external audit. Everything above is our own reading of our own code. Nobody outside the project has checked it, and while that is the case, treat these properties as claims we are prepared to defend rather than as the findings of a review.