A legal order against the QERYX relay compels the operator to produce what the relay holds. This guide is the honest inventory of that set: ciphertext the order-holder cannot decrypt, the conversation roster the relay routes on, connection-level metadata, and each photo or file still within its lifetime with an upload record that names its uploader — and, for destroyed conversations, the sealed one-to-one messages a destroy cannot reach, until their own clock runs out, the files still within their lifetime and, in older backups, end-to-end ciphertext, which on the REST send lane also sits in an envelope whose wrap key exists nowhere outside the operator's own master. The guarantee is architectural: the strongest disclosure policy is having little to disclose.
The question, precisely
"What does a subpoena yield?" decomposes into what the relay stores,
for how long, and what any of it means without keys. The relay is a
carrier: it holds end-to-end ciphertext in transit, opaque routing
identifiers, and operational records — it holds no plaintext of a conversation and no conversation keys, for anyone; the assistant tab is the one path that carries readable text, and the privacy policy states its extent. Reading a session's content requires
breaking both X25519 and ML-KEM-1024.
Read the inventory
| Compelled item | What the order-holder receives |
|---|---|
| Message content |
ChaCha20-Poly1305 ciphertext under per-message keys
the server never held. A delivered message is retired at its delivery receipt and hard-deleted by the sweep within twenty-five minutes. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off are retired without a receipt the relay can match, so they wait, like undelivered messages, for the thirty-day horizon, then purge.
|
| Photos, videos, files, group voice notes | each one encrypted on the sender's device and stored apart from its message, with an upload record naming its uploader, its type, its size and its times — kept up to forty-five days after upload, delivered or not and even after its conversation is destroyed, unless the sender deletes the message for everyone or a chat timer purges it sooner |
| Who talks to whom |
the conversation roster, in the clear. The relay stores
participant_user_ids — a per-conversation array of
raw account IDs, indexed for lookup — because it is the routing
and authorization spine: membership is checked against it on
essentially every request. A database snapshot therefore does
reveal who is in a conversation with whom. Per-conversation blinded participant hashes sit beside it, salted per conversation — but the salt sits on the same row and the profile identifiers sit in the same database, so the hashes narrow nothing an operator holding a snapshot cannot test directly.
|
| Group names, descriptions | end-to-end encrypted content — the relay never receives them; the group avatar, the admin and owner identifiers, and the roster it delivers to are held for routing |
| Sender identity on delivered messages | sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time |
| Undelivered queue | wrapped ciphertext with routing metadata, held under a published retention ladder |
| Destroyed conversations | the rows the relay can tie to the conversation are deleted, and an older backup holds their end-to-end ciphertext, which on the REST send lane also sits in an envelope whose wrap key exists nowhere outside the operator's own master; a one-to-one message, sealed by default, names neither its sender nor its conversation, so the destroy does not reach it, and one still waiting, or read with Stealth Mode on or read receipts off, stays to the thirty-day horizon; the conversation's files stay until their own expiry, unless their sender deleted them sooner (§3) |
Ask about destroyed conversations
When you destroy a conversation, the relay deletes the rows it can tie
to that conversation, and the
FSOR layer advances the
conversation's envelope epoch and zeroizes the old wrap key in process
memory. A one-to-one message is sealed by default and stored without its sender or its conversation, so the destroy does not reach it: it leaves on its own clock, within twenty-five minutes of its delivery receipt, or at the thirty-day horizon if it is still waiting for its reader or was read with Stealth Mode on or read receipts off. The residue of a row written through the REST send path, in backups, write-ahead logs and replicas, stays wrapped under a key that was never written down: against anyone holding the database alone, that outer layer never opens. Rows from every other lane — sealed sender, group fan-out, WebSocket — were never wrapped, so their residue rests on the end-to-end layer alone. Destroying a conversation does not delete its photos and files: each stays until its own expiry, unless its sender deleted it sooner. The operator's own master can re-derive the envelope, so against a compelled operator the guarantee that holds is the inner one — the end-to-end layer, whose keys the relay has never held. Destroying or rotating the master is what closes the outer layer too, and it is a runbook step, not a property of the epoch advance. The destruction root is signed with ML-DSA-87 under the context QERYX-FSOR-ROOT-v1 and published at the audit endpoint, so an account holder will be able to verify it against the operator key served beside it. Surfacing that receipt in the app is in development.
The boundary, stated: for ten minutes after the delivery receipt a grace window exists in which the row is still recoverable with operator cooperation, and the sweep that removes it runs every fifteen — so the outside bound, for a delivered message on the receipt arm, is twenty-five minutes.
What an order can still learn
Honesty requires the other column. Connection-level signals are visible to any server on the internet, and legal process can compel them:
- the address of a connection while it is open — the API host writes no access log, so there is no address history to compel, only the live socket;
- traffic timing and volume — rates, not content;
- an operator under live, ongoing coercion could be compelled to retain inbound ciphertext before the at-rest wrap — still ciphertext, and a policy-and-audit control rather than a cryptographic one. The specification says this plainly, and so do we.
The mitigations are layered, and none of them is claimed absolute: the nine-step padding ladder removes byte-exact message sizes, and cover frames keep the connection carrying traffic when you are not. QLEAP will move your general traffic through multiple hops. It is in development, and by design it will not carry QERYX's own control plane — the relay sees the address you connect from either way, which is why the edge is configured to keep no record of it. The threat model carries the full residual-risk analysis.
References
- The QERYX Threat Model §12.2.15 — the subpoena row with source citations.
- FSOR: Cryptographic Erasure — the destroyed-conversation mechanics and their honest limits.
- Identity and Key Transparency — participant blinding, byte recipe included.