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, blinded participant hashes, connection-level metadata — and, for destroyed conversations, envelope-locked bytes under a key that no longer exists. 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 and no
decryption keys, for anyone. 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. Delivered messages are erased server-side
on delivery; undelivered messages queue under a bounded offline
horizon, then purge.
|
| 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 ship alongside it and genuinely do not
correlate across conversations, but they narrow what the
hashes leak, not what the routing column holds.
|
| Group names, subjects, avatars | end-to-end encrypted content; the relay holds only opaque routing identifiers |
| Sender identity on delivered messages | sender identifiers are stripped from the stored message row (sealed-sender v2), though the relay still authenticates the sender at send time |
| Undelivered queue | wrapped ciphertext with routing metadata, held under a published retention ladder |
| Destroyed conversations | envelope-locked bytes under a retired key that was never persisted (§3) |
Ask about destroyed conversations
When you destroy a conversation, the
FSOR layer advances the
conversation's envelope epoch and zeroizes the old wrap key in process
memory. Residue in backups, write-ahead logs, and replicas stays
wrapped under a key that exists nowhere — recovery would require
breaking the end-to-end layer and the erased envelope both, with or
without operator cooperation. The destruction itself is signed with
ML-DSA-87, so you hold a verifiable receipt that it
happened.
The boundary, stated: for roughly ten minutes after delivery a soft-delete grace window exists in which the wrapped envelope is recoverable with operator cooperation. Past it, it is not.
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:
- IP addresses that connected, and when;
- 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 9-bucket padding ladder removes byte-exact sizes today, and decoy traffic blurs idle patterns today. QLEAP onion routing moves even the connecting IP out of the relay’s view; it is not in this build, so today the relay still sees the connecting IP of a client that does not supply its own transport. 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.