The short version

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

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

Post-quantum, already in the protocol. ML-KEM-768 is encapsulated to the recipient's Kyber prekey at session setup (PQXDH). The first message of a conversation is classical-only by design; everything after it is not.

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 the “stealth” switch.
  • ** An opaque identifier is a string that says nothing about you — characters assigned when the account was created.

What exists today

A second channel, not a replacement for your main messenger. Today that means one-to-one chats and calls on iOS, one server, an early build. No groups, no channels, no sync between your devices — a second channel does not need them.

Technical Architecture

The short version: messages are encrypted on your device, the server moves them without being able to read them, and it does not learn who sent them. The rest of this section is how, for readers who want it.

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

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. Konstruct’s live path is gRPC bidi over QUIC, with HTTP/2 as automatic fallback.

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-768 secret (NIST FIPS 203) to the recipient's Kyber prekey and mixes it into the ratchet root, so a recorded session is not recoverable by breaking X25519 alone. The very first message is classical-only by design; the post-quantum secret applies from the second message onward. On top of that, sessions that negotiate it run a continuous ML-KEM-768 ratchet — re-keying as the conversation goes, not once at setup.
  • 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.
  • 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; 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.
  • Crypto Agility: the protocol carries a suite version, so devices running different algorithm sets keep talking while a migration rolls out — no flag day, no requirement that everyone update at once. Adding an algorithm still means shipping a new build; what versioning removes is the need for it to happen everywhere simultaneously.

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, and about the message itself only its size and the time it arrived. Exactly what routing ciphertext requires.

Always-on sealed sender removes the sender's identifier from the message's metadata. The recipient can reveal who wrote it; the server cannot.

The server holds public keys and ciphertext, never plaintext, and does not see who sent a message — only the recipient, the time and the size. Timing and IP stay visible on the wire. Today the network is a single trusted server.

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 to disk: when logs are needed to fix a bug, you send them yourself with a button in a beta build. 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, push token — 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-768 (Kyber-768) is encapsulated to the recipient's Kyber prekey at session setup (PQXDH), and sessions that negotiate it also re-key continuously inside the Double Ratchet. Signatures are hybrid Ed25519 + ML-DSA-65 (Dilithium-3): the crypto is implemented and cross-verified between client and server; client-side key rotation is still being wired up.
  • 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.