Skip to content

Architecture

Trust Model

Everything rests on one rule: the server holds no authority, ever. If a server can be replaced without touching clients, it follows that it was never trusted by clients — only authorized. A Barid node is a bag of bandwidth holding a leaf certificate that says "the root vouches for me, until Tuesday." Burn it, sign another, done.

graph TD
    ROOT["🔑 Root key<br/><i>offline, operator-held</i>"]
    MAN["📄 Manifest<br/><i>signed, versioned</i>"]
    CERT["📜 Leaf certs<br/><i>30-day expiry</i>"]
    DEV["📱 Device identity<br/><i>issued at enrollment</i>"]
    CELL["🖥️ Barid nodes (cells)<br/><i>disposable</i>"]

    ROOT -->|signs| MAN
    ROOT -->|signs| CERT
    ROOT -->|signs| DEV
    CERT -->|presented by| CELL
    MAN -->|describes| CELL

    style ROOT fill:#c1121f,color:#fff,stroke:#8c0c16
    style CELL fill:#f5f5f5,color:#111,stroke:#e4e4e7

1. The root key is the only trust anchor

A single Ed25519 root keypair, held offline on operator-controlled devices. Clients ship with the root public key baked in — and nothing else. No server addresses, no server certificates, no per-deployment configuration.

The consequence is the whole design goal: any Barid node can be destroyed and replaced without touching a single client, because no client ever relied on anything a node holds.

The client's only permanent knowledge is the root public key

If a client must be updated when infrastructure rotates, the design has failed. The one baked-in constant is the root public key.

Root key loss is the only unrecoverable event

Lose the root key and the network freezes: no new manifest can be signed, so every client is stranded on the last one it saw, forever. This single point of failure is defended, not wished away:

  • Shamir secret sharing, split across three operator devices — no single device holds the key.
  • A second offline root key, pre-authorized in every client from the first release, as a break-glass successor.

2. Servers hold no authoritative state

A Barid node's entire state is derivable from the signed roster. There are no server-generated identifiers and no server-side source of truth. Message queues are ephemeral ciphertext; losing them drops messages but breaks nothing.

Recovery is mechanical: install the binary, feed it the signed backup bundle, let it verify the root signature and rebuild. The bundle contains:

  • the root keypair (the one thing that genuinely cannot be lost),
  • the device roster — pubkey → label, cell assignment, status, issued-at,
  • the current manifest.

3. Server certificates are short-lived

Leaf certificates expire in 30 days and are re-signed monthly from an operator device. Expiry is the revocation mechanism — there is no CRL and no distributed revocation state to keep consistent. A burned server's certificate dies on its own schedule. For anything urgent, a manifest bump handles it immediately.

This is the single largest complexity saving in the design, and it is only possible because the root key is offline and re-signing is cheap.

4. Operations staff cannot issue identity

The ops team — a handful of fully trusted engineers — deploys, rotates, and burns Barid nodes. The root key never touches server infrastructure, so they are structurally incapable of enrolling a device or signing a manifest.

This is protective, not adversarial. An engineer who cannot issue identities cannot be coerced or phished into doing so. The honest case and the hostile case look identical from the system's perspective, which is the only property that survives someone having a bad year.

How the pieces earn their keep

Piece Held by Lifetime If compromised
Root key Operator, offline Permanent Catastrophic — defended by Shamir + successor key
Manifest Anyone (public) Until superseded Stale copy at worst; cannot be forged
Leaf cert Barid node 30 days Expires on its own; burn + re-sign
Cell secret Client Until rotated One cell's future addresses leak
Device identity Client Until revoked One device; revoke via roster

Read next: the manifest — the only channel through which a running network is reconfigured.