QERYX COMING SOON
OBSERVATORY

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.

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.

rerun open() on a corrupted frame

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 crypto-core module itself.

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 and descriptions and all content are end-to-end encrypted; the group avatar, the admin and owner identifiers, and the roster of accounts each conversation delivers to are held by the relay for routing. Sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time and keeps a per-direction pair counter for up to 180 days. Sealed sender covers text-class messages and small payloads: an image, and any voice or video frame over the envelope budget, is delivered on a lane that does name the sender to the relay for as long as the row lives. Undelivered messages queue with routing metadata under a published retention ladder.

Holds, briefly. Cannot hold, ever.

What the relay holds of a message — the full retention ledger is on /legal/privacy
  • queued ciphertext Sealed bodies awaiting delivery — held at most 30 days1, then purged by the sweep that runs every fifteen minutes. A delivered row is deleted within about 25 minutes of the delivery receipt; a group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off wait for the 30-day horizon. Held
  • media files A photo, video, file or group voice note, encrypted on the sender’s device and stored apart from its message, with an upload record that names the uploader — held up to 45 days after upload, unless the sender deletes the message for everyone or a chat timer purges it sooner. Held
  • routing identifiers The account UUIDs a conversation delivers to, plus the group admin, owner and creator identifiers. They carry no phone number, e-mail or display name; they do link a conversation to its accounts. 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

The hard questions.

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.

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 key transparency log — one operator-signed root your device verifies against an anchor compiled into the app and cross-checks through gossip; the 2-of-3 witness quorum starts dormant — exist to catch.

So a phone that is off for a week still receives its messages. The 30-day period1 is the published default; a shorter tiered retention ladder is on the roadmap, and this page will state it in the present tense only when it ships.