What the server keeps
Encryption protects what you said. It does not hide the fact that a conversation happened, and we would rather show you the difference than describe it. This page lists what a server running this software actually stores, so you can check the answer instead of taking our word for it.
The short version
- The server keeps who a message is for and when it arrived, because it cannot deliver it otherwise.
- It keeps the message itself, still locked, until your app collects it — and it holds nothing that would open it.
- It keeps your account details: username, email, password (stored scrambled), and the public half of your keys.
- It does not keep a record of when you added a friend, blocked someone, or joined a group. Those were removed on purpose.
- Its own logs contain no account, device or address unless an operator deliberately turns on detailed logging.
The rest of this page is the same answer with every field spelled out.
Held while a message is in flight
| Kept | Why it has to be | Gone after |
|---|---|---|
| Recipient account and device | An envelope cannot be delivered without an address | 1 day once delivered |
| Arrival time and approximate size | Ordering, and the size is the ciphertext itself | 1 day once delivered |
| Sender account and device | Identified sends only — a sealed send stores neither | 1 day once delivered |
| The ciphertext | It is the message; the server holds no key that opens it | 30 days if never collected |
Held for as long as the account exists
| Kept | Why |
|---|---|
| Username, email, password hash, display name | It is an account |
| Public keys per device | They are published on purpose — that is what a prekey bundle is |
| Buddy list, blocks, group rosters | The server enforces them, so it has to know them |
| Presence | Coarsened to the online window before it is written, never to the second |
| Delivery-key digest | The hash only. The key itself never reaches the server except inside a sealed submission |
Deliberately not kept
These were removed rather than retained. Each was written and never read, which made them a durable record of how a social graph formed in exchange for nothing:
- Who uploaded an attachment. The load-bearing one: a sealed envelope stores no sender, and then the attachment it pointed at named the uploader for the life of the blob.
- When a buddy was added.
- When a block was set.
- When someone joined a group.
Logs
The server logs errors and criticals only. On a healthy day it
writes nothing at all, which is the quietest setting that still tells an operator
when something is wrong. Everything below that has to be switched on deliberately:
info narrates start-up and retention sweeps, and debug
records request URLs and every database query — a protocol URL contains a device id,
which would turn the log file into a durable record of who fetched whose keys, in a
place nothing sweeps.
Whatever sits in front of the server keeps its own access log. That is the operator's to configure, and on a server you run, the operator is you.
What none of this changes
A server necessarily observes the connection that delivered a message, including its address. Sealed sender removes the sender from the stored row, not from the network. Anyone claiming a hosted messenger is metadata-free is describing something else.
See also the privacy policy for the retention windows in full, and self-hosting for how to change them.