03 Security · Zero-Knowledge
Open it yourself. The relay never can.
The server is a dumb encrypted blob relay. It cannot read messages — the keys are born and die on your devices.
01Feel it — real ChaCha20-Poly1305, in this page
Do the one thing the relay cannot.
Below is real ChaCha20-Poly1305 ciphertext — the exact shape the relay carries. You hold the key; it never does. Tap to decrypt.
Real ChaCha20-Poly1305 (RFC 8439), compiled from Rust to WebAssembly, running in your browser. Same primitive family as the QERYX protocol; demo build, not the shipped crypto-core module.
02The carrier model — architecture, not policy
Follow the herald who holds nothing of his own.
Zero-knowledge here is architecture, not policy: encryption and decryption happen only on devices, so the relay’s ignorance is a property of where the keys live, not a promise about behavior. A subpoena can compel everything the server holds — which is why the inventory of what it holds is published, field by field, on the Server Ledger.
Message bodies are sealed with ChaCha20-Poly1305 under Q-Ratchet keys that rotate per message. Group names, subjects, avatars, and all content are end-to-end encrypted; the relay holds only opaque routing identifiers; sender identifiers are stripped from the stored message row (sealed-sender v2), though the relay still authenticates the sender at send time. Undelivered messages queue with routing metadata under a published retention ladder.
03The inventory — held briefly, or never present
Holds, briefly. Cannot hold, ever.
- queued ciphertext Sealed bodies awaiting delivery — held at most 30 days1, then purged by the hourly job. Delivered rows are erased on acknowledgment. Held
- routing identifiers Opaque tokens and blinded commitments — enough to move an envelope, nothing that names you in the clear. Held
- message keys Never present. Born on your device, rotated per message by Q-Ratchet, dead after use. Cannot hold
- plaintext Never present. No server-side decryption path exists in the codebase. Cannot hold
- escrow / master reset Never present. There is no key-escrow and no master reset — for anyone, including us. Cannot hold
04The record — the questions we get asked hardest
The hard questions.
If the server is so dumb, how do push notifications work?
The notification service receives a wake signal, not content. The sealed payload is fetched and decrypted on your device; the preview you see is rendered locally after decryption.
Could a malicious server version read messages?
A hostile relay can drop, delay, or refuse messages — it still cannot read them, because no key ever reaches it. What it could try is substituting keys during pairing; that is exactly what safety-number verification and the 2-of-3 multi-witness key-transparency quorum (verify-only today — operator equivocation is detected, not prevented) exist to catch.
Why does the queue keep messages for 30 days?
So a phone that is off for a week still receives its messages. The 30-day period1 is the published present-tense truth; a shorter tiered retention ladder is on the roadmap, and this page will state it in the present tense only when it ships.