ECHO · THE RELAY

Infrastructure, assumed hostile.

Reference relay v0.1 · stores sealed boxes · cannot open them

The relay is the one piece of Echo that lives on a server you don't control. So it is built to hold nothing but ciphertext — and to keep working even if the server itself is the adversary.

A correct design holds when the server is the adversary. This page runs that design, for real, in your browser.
Governed by the Core Laws. The Relay is where Laws 6, 10 & 11 meet the wire — visible access, hostile infrastructure, proof never data.Read the Laws →
SEALED-BOX SYNC · LIVE

Two devices, one encrypted memory, a relay that never sees it.

Device A encrypts a memory on-device, pads it, and uploads. The relay stores the opaque bytes. Device B — sharing the vault key out-of-band, never through the relay — syncs, downloads, and decrypts locally. The vault key and the plaintext never leave the browser.

Real Ed25519 + AES-256-GCM run in your browser. Open DevTools → Network and watch: only ciphertext ever leaves this page.

WHY IT HOLDS

The relay is built to be untrusted.

§4 · Signed requests

Every write is signed with the device's Ed25519 key over METHOD·PATH·TS·NONCE·SHA256(body). No valid signature, no access.

§7 · Padding buckets

Sealed boxes are padded to fixed sizes, so the relay learns nothing from the length of what you store.

§10 · Plaintext guard

A best-effort safety net that rejects anything that looks like plaintext or a recovery fragment. It catches a buggy client — it is never a guarantee.

Replay + quotas

Each nonce is single-use (shared store), bodies are size-capped before they're read, and each vault has device and storage quotas. The server assumes it is under attack.

The honest edge (Law 6): the relay sees no content, ever — but it does observe metadata like timing, sizes (bucketed), and which device is talking. Echo keeps "no content" absolutely; it never claims "no metadata."