Messages that vanish on a timer the relay is never told.

What the relay deletes

Your messages reach the relay as end-to-end ciphertext it has no key to. A delivered row is purged after the grace window, and destroying a conversation deletes the rows the relay can tie to it; a one-to-one message, sealed by default, names neither its sender nor its conversation, so the destroy does not reach it, and it leaves on its own clock, as any message does. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off wait for the offline horizon instead. A photo, video, file or group voice note is stored apart from its message, encrypted, and stays up to 45 days after upload, even after its conversation is destroyed, unless the sender deletes the message for everyone or a chat timer purges it sooner. Nothing on the database volume is overwritten, so bytes left in a WAL or a backup are that same ciphertext, beside the routing columns that name who wrote to whom.

Rows that arrive on the relay’s REST send lane also sit inside a second, server-side envelope whose key is derived at use, and never stored, from an operator master held in the relay’s environment. Destroying the conversation retires that envelope’s epoch: to anyone without the master its residue never opened, and against someone who holds the master the retirement is policy, not mathematics.

Wrap key

HKDF from the erasure master key in the relay’s environment · derived at use, never stored

Residue

end-to-end ciphertext · envelope-locked on REST-lane rows

Source

fsor.rs · SPEC/06

The receipt

Every destruction emits a Merkle root over the erased messages, signed under ML-DSA-87 and published at the audit endpoint, so an account holder will be able to verify it against the operator key served beside it. A receipt records that the relay deleted a row; it cannot prove that no copy of the bytes survives on a disk. Verifying and showing that receipt in the app is in development.

Receipt

ML-DSA-87 · ctx QERYX-FSOR-ROOT-v1

Verify against

TOFU-pinned operator key

Source

SPEC/06 §8.9

Sealed sender wire v1

The outer envelope names only the recipient; the sender's identity sits inside the seal and is readable only after decryption — the stored row carries no author at all. On the recipient's acknowledgment the row is marked deleted and stops being deliverable; the purge sweep destroys it within the following twenty-five minutes, and the destruction is receipted. A group message is sealed to each member as a row of its own, which the member's receipt does not match: that row, like a message read with Stealth Mode on or read receipts off, is retired without a receipt and waits for the offline horizon. Rows the recipient can never open — control events and undeliverable sealed blobs — are minimised on the spot: sender, recipient and content all cleared.

On ack

marked deleted, no longer deliverable

Then

destroyed by the sweep within 25 minutes, with a signed receipt · thirty-day offline horizon

A group member’s row, or a read without a receipt

retired without a receipt the relay can match · destroyed at the offline horizon

Source

SealedSenderService.swift · sender_cert_handlers.rs

Duress

A decoy PIN opens a believable decoy surface; the real account is scoped out of that unlock's view once duress fires — the decoy PIN re-scopes the messenger, it does not re-key it. Activation is the duress PIN itself, nothing quieter.

Decoy

decoy surface · opens under the duress PIN

Real account

out of that unlock’s view · re-scoped, not re-keyed