Spectr — Privacy Policy
Last updated: 30 July 2026
Spectr is an end-to-end encrypted messenger. This policy describes exactly what the service can and cannot see. It is written to be accurate rather than reassuring: where Spectr holds data, or where a protection is not yet complete, it says so plainly.
1. No account, no phone number, no email
Spectr does not ask for a phone number, an email address, or any other real-world identifier. Your identity is a cryptographic key pair generated on your device from a 24-word recovery phrase. We cannot reset it, recover it, or link it to you.
2. What the server can never read
Message text, photos, videos, voice notes, files, stickers and story content are encrypted on your device before they are sent, using the Signal-style X3DH key agreement and Double Ratchet protocol. The server relays ciphertext. It does not hold the keys and cannot decrypt any of it. This also applies to your encrypted backups.
Calls are peer-to-peer and media is encrypted with DTLS-SRTP. When a direct connection is not possible, encrypted call media is relayed through our TURN server, which likewise cannot read it.
3. What the server does hold
This is the part most policies are vague about. Concretely:
| Data | Why | Retention |
|---|---|---|
| Routing hash (a 128-bit identifier derived from your key) | To deliver messages to the right mailbox | While the account exists |
| Undelivered messages: ciphertext, plus the sender's public key, key fingerprint and chosen display name, and a timestamp | So a message sent while you are offline still arrives | Deleted once your device confirms it has the message; otherwise 7 days |
| Public prekey bundles | So others can start an encrypted session with you while you are offline | While the account exists |
| Encrypted backup blobs | So you can restore on a new device | 180 days after the last update |
| Encrypted media blobs | Attachment delivery | Until expiry or deletion |
| Aggregate counters (installs, invites accepted, daily active) | To know whether the product is growing | Indefinitely, as totals only |
| Web server request logs, including your IP address | Abuse prevention, rate limiting, debugging | 14 days, then deleted by rotation |
| Push subscription — the notification endpoint URL issued by Apple, Google or Mozilla for your device, plus its encryption keys, stored against your routing hash | To notify you of a new message when the app is closed | Until you turn notifications off, or the endpoint stops working |
| Channel activity — which channels you subscribe to, which posts you have opened, which posts you reacted to and with what, and how you voted in a poll. Stored against a channel pseudonym, not your routing hash — see below | Subscriber counts, view counts, reaction tallies and poll results | Until you unsubscribe, the post is deleted, or you delete your account. There is no automatic expiry |
| Comments you leave on a channel post — the text, any attached media, and the display name you posted under. Stored against the same channel pseudonym | They are shown publicly under the post, which is the point of a comment | Until the post or channel is deleted, or you delete your account. There is no automatic expiry |
| Channels you create: name, description and your public key as owner | They are public by design | Until you delete the channel or your account |
| Group membership — a group id, its name, and the routing hashes of its members | To fan a group message out to the right mailboxes | Until you leave the group or delete your account |
| Directory entry, only if you claim a username — that username, your display name and your public key | So people can find you by @username | Until you release the username or delete your account |
On channel activity, honestly. This is the one part of Spectr with no expiry date on it. A subscription, a reaction, a view and a poll vote are all stored until something removes them, and until recently nothing could: deleting a post left its reactions and votes behind, and there was no way to delete an account at all. Both are fixed — a deleted post takes its reactions, views and votes with it, and Delete account removes the lot — but we would rather describe the shape of it than let the table above imply a retention period that does not exist.
These rows are keyed to a channel pseudonym: 128 random bits generated on your device the first time you interact with a channel. It is not derived from your identity key and the server cannot connect the two. That is a real protection and it is also not anonymity — the same pseudonym appears on everything you do in channels, so the server can see that one participant subscribed to these channels and voted this way, and your IP address sits beside both that pseudonym and your routing hash in the request logs for 14 days. If you watch a channel's live stream, your pseudonym is also given to the person broadcasting it — the peer-to-peer video connection has to be addressed to something.
Channels are a public broadcast medium. Nothing you do in one is end-to-end encrypted, and none of this section applies to your private chats or groups, which are.
On push notifications, honestly. If you enable notifications, the server stores a device-specific endpoint against your routing hash. That is a durable link between your account and one device, and it is the single biggest thing the server knows about you. We considered not offering notifications at all; a messenger that cannot tell you about a message is not much use, so we made the same trade every other encrypted messenger makes — and we would rather write it down here than let you assume otherwise.
The notification itself is contentless: it says only "New message". No sender, no preview, no count. Your device fetches and decrypts locally once woken, so neither we nor Apple, Google or Mozilla learn anything about the message beyond the fact that one arrived. Notifications are off until you turn them on, and turning them off deletes the subscription.
On metadata, honestly. Message content is encrypted end-to-end and the server cannot read it. Who sent it is a different question, and the honest answer is that the server can see it.
Every message travels in an envelope that names the sender's public keys and chosen display name in the clear — the encrypted part is the message body inside it. The server needs enough of that to hand the message to the right person. So on every message, delivered live or not, the server can observe that one identifier sent to another, and when. While a message waits for you to come online it also stores that alongside your routing hash, until your device confirms it has the message or seven days pass.
We do not build a contact graph, we do not keep a record after delivery, and we do not sell or share any of it. But a server that is blind to who talks to whom would require hiding the sender inside the encrypted part, and Spectr does not do that yet. We would rather write that down than let the phrase "metadata-blind" do work it has not earned. It is on the roadmap; until it ships, this page describes what is actually true.
4. Aggregate analytics only
Spectr counts events (an install happened, an invite was accepted, an account was active today). These are counters with no identifier attached — no routing hash, no IP, no per-event timestamp — and the counter names are restricted to a fixed list. There is no third-party analytics, no advertising SDK, and no tracking across apps or websites.
5. Encryption of keys stored on your device
Known limitation. Spectr encrypts your identity keys at rest on your device only once it can prove the device-held encryption key survives a restart. On some platforms and during the first session, that proof is not available and the keys are stored unencrypted in browser storage. Anyone with access to your unlocked device, or to its storage, could read them. We are addressing this; until we can say it works everywhere, we prefer to state it than to imply protection you do not have.
Treat physical access to your unlocked device as full access to your messages.
6. Reports and abuse
You can block any user, and you can report one. A report sends us the reported user's public key, their key fingerprint, your own public key, and the category you chose. It does not send any message content — we could not read it in any case. Reports go to the operator and are used to identify patterns of abuse.
Bug reports you submit may include diagnostic details, which are always shown to you in full before anything is sent.
7. Deleting your data
There are two separate actions, and they do different things.
Settings → Data → Delete all data erases your keys, chats and media from this device. It does not touch the server. Your 24-word phrase still restores the account elsewhere.
Settings → Data → Delete account tells the relay to erase everything it holds for you, and then wipes the device. Specifically: your prekey bundles, your profile, your encrypted backup, your push subscription, any undelivered messages waiting for you, your channel subscriptions, views, reactions, poll votes and comments, your directory username if you claimed one, and any channels you created. Your routing hash is removed from every group you were in; a group with other people still in it keeps working without you. This is irreversible, and your recovery phrase will not bring any of it back.
Three honest limits. Messages you sent that are still undelivered to someone else are not erased on request — they are addressed to that person, and we deliberately do not accept a claim about which sender key is yours, because accepting one would let anybody delete anybody else's queued mail. They expire on the normal 7-day schedule. And a message you already sent that the recipient has received is on their device; deleting your account cannot reach it, in the same way deleting an email account does not unsend your email.
The third limit is narrower and it has an end date. Channel activity recorded before August 2026 — comments in particular — was stored without anything tying it to its author, so there is no predicate that can find it and it survives account deletion. This affects only accounts that existed before that date, nothing created since is affected, and it is a gap we could not close retroactively without guessing at whose rows were whose. Everything recorded from that build onward is erasable.
No identity, email or phone number is attached to any of this, so we cannot verify a deletion request any way other than by the key: erasure requires a signature from your identity key, which means it can only be requested from a device that still has your account on it.
8. Sharing
We do not sell data and we have no advertising partners. We use no third-party processors other than our own hosting and CDN provider, which necessarily handles network traffic. If we are compelled by lawful process, we can only produce what we actually hold — see section 3.
9. Children
Spectr is not directed at children. The service carries unfiltered user-to-user communication and is intended for adults.
10. Beta status
Spectr is pre-release software. It has not had an independent security audit, and its builds are not yet reproducible. Encrypted history may be lost by a protocol upgrade or a bug. Do not rely on it as your only copy of anything important, and do not use it where a compromise would put you at serious risk until an audit has been published.
11. Changes and contact
Material changes will be reflected in the "last updated" date above. Questions and privacy requests: use Settings → Report a problem in the app, which reaches the operator directly.