Operations

Burn & Replace

The founding requirement: if a server is compromised, throw it in the fire and spin up another — without touching the client side. This page is that procedure, and the properties that make it possible.

The one rule that makes it work

A server can be replaced without touching clients only if it was never trusted by clients — only authorized. So no Barid node holds authority, and no node holds authoritative state. Everything a node has is either public (the manifest, its cert) or ephemeral (ciphertext queues) or derivable (from the signed roster). See the trust model.

Burning a compromised node

sequenceDiagram
    participant Op as Operator (root key, offline)
    participant Net as Network
    participant Cl as Clients

    Note over Op: node 17 suspected compromised
    Op->>Op: sign manifest v48 without node 17
    Op->>Op: rotate affected cell secret(s)
    Op->>Net: stand up replacement (new cert, re-signed)
    Op->>Net: publish v48 (any path)
    Net-->>Cl: v48 propagates (server / gossip / cold-start)
    Note over Cl: verify root sig ✓, 48 > 47 ✓<br/>converge automatically

1. Sign manifest v48 without the burned node.
2. Rotate the affected cell secret(s) — this invalidates every address the old secret produced and is what actually revokes a suspected-stolen key.
3. Stand up the replacement, its cert freshly re-signed from the root device.
4. Publish v48 through any available path.
5. Clients converge on their own. No client was touched.

A burned node can, at worst, keep serving a stale manifest to clients that reach only it — a delay, never a redirect, because the version gate rejects anything older and the node cannot forge anything newer.

Restoring from backup

The entire recoverable state of the network is one signed, encrypted backup bundle:

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

Restore is mechanical: install the Barid binary, feed it the bundle, it verifies the root signature and rebuilds. Nothing on a server may be authoritative — no server-generated IDs, no state not derivable from the roster. Losing a node's message queues drops in-flight messages; it does not break the network.

The backup you actually carry

The roster is designed to be the one thing the operator keeps personally, easy to back up to a few of their own devices. Reinstalling a whole machine is: install binary → feed bundle → done. The roster is a single-writer artifact precisely so it stays this portable — see enrollment.

What can and cannot be recovered

Lost	Recoverable?	How
A Barid node	Yes, trivially	Reinstall, feed bundle, converge
A node's message queues	No, but harmless	Ephemeral ciphertext; a dropped message
The manifest	Yes	Re-sign from root; it is public anyway
A client device	Yes	Re-enroll in person; revoke old via roster
The root key	No	The catastrophic case — defended by Shamir split + a pre-authorized successor key

The whole design collapses to one sentence: everything except the root key is disposable, and the root key never touches anything that runs.