Architecture Overview

Orientation chapter. This is the map of the whole system: how the cryptographic core (Message Encryption) and the Transport Layer fit together, and how Konstruct stays reachable as a network operator turns hostile. It is descriptive architecture — normative (RFC 2119) requirements live in the per-component chapters it points to. For the authoritative per-component build state, see Implementation Status.

Konstruct is a layered system with one invariant at the bottom and a ladder of reachability strategies above it. The invariant: end-to-end encryption is always on and never depends on any server (see Threat Model and Message Encryption). Everything above the crypto core exists to answer a single question — can this message reach its recipient? — as the network becomes more adversarial, degrading gracefully from a fast direct connection down to a device-to-device mesh that needs no network at all.

Design position

Four goals pull against one another. Konstruct takes a deliberate position rather than pretending to maximise all four at once:

The anonymity position is load-bearing enough to state precisely. Konstruct provides pseudonymity with no real-world anchor, not unlinkability against a global observer:

A mixnet (Sphinx packets, per-hop cover traffic) would add network-layer unlinkability at a large cost to usability and — being enumerable — to censorship-resistance itself. For Konstruct's users that tradeoff is not worth it; the sealed-sender ceiling is the accepted metadata boundary.

The layered model

Above the always-on cryptographic floor, the system is five layers plus an offline foundation. Each is a distinct concern with its own implementation; they are composed, not merged.

   always-on floor ─── E2EE (Double Ratchet · sealed sender)  ·  identity = public key (no PII)
   ══════════════════════════════════════════════════════════════════════════════════════
   ▲ outward path
   │  Transport        move bytes + obfuscation   (QUIC/H3 · veil-front HTTPS · H2 fallback)
   │  EntryDirectory   find a reachable, un-burned entry point
   │  RouteLayer       a single proxy hop that hides the user's IP from the server
   │  Overlay          location-independent addressing & discovery (route_id, DHT)
   │  Delivery         federation, store-and-forward, trust posture
   ▼
   Mesh floor          device-to-device with no network at all   (foundation)

route_id is the SHA-256 of the account's identity public key. Because it is derived from the key and carries no location, an account can move between servers (or onto a domestic island, or onto the mesh) and remain addressable — this is what makes zero-configuration re-homing and the offline mesh share one identity model.

Graceful degradation by network tier

The layers active at any moment depend on how hostile the network is. The same system reconfigures itself down the ladder:

Two properties of this table matter. First, obfuscation answers "can they tell what this is?", not "can this arrive at all?" — under an allowlist the censor drops a packet by destination before inspecting it, so the answer there is not a better disguise but an in-zone deployment that never needs to cross the border (in-country federation, a domestic-only overlay). Second, veil-front has no transport fallback beneath it; if its relay is blocked, reachability depends on the EntryDirectory layer having diverse entries, and ultimately on the mesh floor. The layers are coupled: finishing the transport is not the same as finishing censorship-resistance.

The offline mesh floor (design)

The lowest rung keeps two people messaging with no infrastructure at all — a total blackout or a fully sealed island. It is a parallel offline mini-stack that supplies its own addressing, routing, and store-carry-forward, and it carries opaque Konstruct end-to-end payloads — it does not replace the message crypto.

The design direction adopts Reticulum (a cryptographic networking stack that routes over any medium) as the overlay, for two reasons: its destination addressing is a hash of a public key, which maps directly onto Konstruct's route_id; and it is medium-agnostic, so "which radio" becomes a pluggable interface rather than a new routing engine.

Message security remains Konstruct's end-to-end layer; a mesh relay learns no more than an online sealed-sender relay does. This rung is analysis-stage: the gating questions are the Rust implementation path and cross-platform local interoperability, to be resolved by a laptop-first spike before any mobile work.

What the architecture does and does not provide

Consistent with Transport §6.6, stated for the whole system:

Provided: content confidentiality and integrity (E2EE, always on); no link between an account and a real-world person; sealed sender removing sender identity and the at-rest social graph from delivery; the user's IP hidden from the home server; the home server's IP hidden from the censor; and continued operation as the network degrades — including, by design, with no network.

Not provided: unlinkability of who-talks-to-whom against an adversary who observes both ends or correlates timing; recipient identity at the delivering node; connection metadata (times, sizes, IPs a relay itself sees). A single relay hop is IP-hiding, not anonymity, and Konstruct does not claim otherwise.

Where the detail lives