Spectr — Privacy Policy
Last updated: 1 September 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.
Post-quantum, and its limit. Setting up a conversation now uses a hybrid key agreement: the classical X25519 exchange and ML-KEM-768, the NIST-standardised post-quantum algorithm, combined so that an attacker has to break both. That is aimed at one specific threat — somebody recording your traffic today to decrypt it years from now, once a quantum computer exists. Recording a Spectr conversation today does not give them that.
The ratchet that runs for the rest of the conversation is now post-quantum as well. It keeps mixing fresh ML-KEM-768 secrets in as you talk, so if someone were to steal the live encryption state off one of the two devices, the conversation heals back out of their reach — and it does so even against an attacker holding a quantum computer, which was not true before 19 August 2026.
Where it stops, so that “post-quantum” does not read as a blanket claim: this protects the contents of your conversations. It does nothing about the delivery metadata described in section 3 — when you connect, and the size and timing of what you send. And none of it has been reviewed by anyone outside the project.
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 | 30 days from upload, or until you delete the message |
| Presence — the fact that some device is currently holding a live connection for your routing hash, and which relay process it is on. Not who you are talking to, and not for how long | To route a live message to the right process instead of storing it | Two minutes, refreshed while you stay connected. Nothing is written down when you disconnect |
| Short-lived abuse counters — a count of recent connection attempts against your routing hash, and the random id of each message we have already seen, so a duplicate is not delivered twice | Rate limiting per account rather than per IP address, so one person cannot spend a whole mobile network's allowance | Two minutes and five minutes respectively. Counts and message ids only — no content, no sender, no recipient |
| Aggregate counters (installs, invites accepted, daily active) | To know whether the product is growing | Indefinitely, as totals only |
| Reports and enforcement records — a report you send about someone, or one somebody sends about you: the reported public key and fingerprint, the reporter's public key, the category, and any suspension that follows | To act on abuse, and to recognise a repeat pattern rather than treating each report as the first | Indefinitely, and they survive account deletion. See §6 |
| Web server request logs, including your IP address | Abuse prevention, rate limiting, debugging | 14 days, then deleted by rotation |
| Push subscription — for a browser or the PWA, the notification endpoint URL issued by Apple, Google or Mozilla plus its encryption keys; for the native iOS app, the Apple Push Notification service device token, the alert text your device asked us to display, and your notification-privacy setting. 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: no sender, no preview, no message text. Your device fetches and decrypts locally once woken. Two details are worth stating plainly rather than leaving you to assume the best of us:
- The alert text is a fixed string your own device supplied when it registered, in your own language, and there is a different one for a direct message, a group message and an incoming call. So Apple can see which of those three arrived — not from whom, and not what it said. A call is also marked time-sensitive so it can reach you through Focus, which Apple sees too.
- On iOS the alert carries an opaque grouping tag so your phone can stack a conversation into one notification instead of a row of separate banners. It is a keyed hash, not your contact's address, and it cannot be linked to anything else we hold — but it does let Apple count how many distinct conversations wake your device. Setting Settings → Notifications to nothing at all removes the tag, at the cost of the stacking.
Apple learns, unavoidably, that your device received a push at a given moment. That is true of every iOS messenger, Signal included; the alternative is an app that cannot tell you about a message. 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.
Cookies and local storage
Spectr sets no cookies. Not on the website, not in the app, not for analytics
and not for sessions — the relay sends no Set-Cookie header at all, and you can check
that yourself with any browser's network inspector. There is nothing to opt out of because nothing
is being placed on you.
What the app does use is your browser's own local storage, on your device: your keys, your contacts and your message history live there so the app can work offline and so the server never has to hold them. That data is never transmitted to us. Clearing your browser data or deleting the app erases it — and, if you have no other device and no recovery phrase, it is unrecoverable, which is the intended trade.
The website shows a notice recording your choice about optional analytics. There are none today; the choice is stored so that if any are ever added they cannot load without it. That record is kept in local storage on your device, not sent to us.
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.
You can set a password, and it is worth doing. Settings → Key password protection encrypts your recovery phrase and every private key with a key derived from that password, removes the unencrypted copies from the device, and asks for it before the app will open. It is off by default, so if you have not switched it on, it is not protecting you.
Use words rather than digits. The screen shows you how strong your choice is as you type, because the difference matters more than it looks: somebody who has your device does not have to try guesses one at a time, and a few words are many millions of times harder to work through than a short numeric PIN.
If you forget it, your 24 words still restore the account — a password can lock the app, it can never lock you out permanently.
Why this matters more here than in most messengers. Your 24-word recovery phrase is not just a backup: every key your account uses is derived from it. One phrase is the whole account, on every device, forever. Anyone who reads it has your account until you move to a new one, and there is no server-side action that can revoke it for you — which is the cost of an account no server controls.
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.
How long we keep them, plainly. A report, the evidence attached to it, and any suspension that results are kept indefinitely, and — unlike everything else in §3 — they are not erased when you delete your account. A report is a record of something that happened between two people, and letting either of them delete it by leaving would defeat the only mechanism there is for recognising a repeat offender. It is also the reason Delete account cannot be a way to reset a suspension.
These records hold public keys, key fingerprints, a category and a timestamp. They never hold message content, because there is none we can read.
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.
Four 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.
The fourth is deliberate rather than technical: abuse reports and suspensions are not erased. A report someone filed about you, and any suspension that followed, outlive the account — otherwise deleting an account would be a way to clear one's own record. §6 sets out exactly what those rows contain.
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.
Operator
Spectr is operated by an individual, not a company. Under Russian Federal Law 152-FZ the operator has to be identifiable rather than implied, so:
| Operator | Mamedov Eldar Ilgarovich (Мамедов Эльдар Ильгарович) |
| Tax ID (ИНН) | 500404335951 |
| Register of personal-data operators | reg. no. 77-25-498474 |
| Address | Moscow, Russia |
| Contact | Settings → Report a problem in the app |
Where the server is. The relay runs in the Netherlands. Spectr is designed so that the server holds no readable content and no name, phone number or email — but if you are in Russia, the routing and IP metadata described in section 3 is handled outside Russia. We would rather state that plainly than let the absence of a sentence imply otherwise.