Security

How the promise is kept.

Everywhere else on this site we claim that spam and scams cannot reach you here, and that we cannot read what you send. Those are engineering claims, so this page describes the engineering, including the parts that are unfinished and the attacks this design does not stop.

Last updated 19 August 2026. Describing the software as it is built today, not as it is planned. Section 9 is the difference between the two.

1. The rule the rest of it rests on

A message can only travel along a channel, and a channel exists only when two people have each accepted the other. There is no way to address a person you have not connected to, because there is no identifier to address them by and no directory to find them in.

This is worth separating from what other apps mean by safety. A spam filter decides whether to show you a message that was already delivered to you. Here the message is never accepted for delivery in the first place: the relay has nowhere to put a payload aimed at somebody who has not accepted the sender, and refuses it. There is no inbox for strangers, no requests folder, and nothing held back for review.

Connections are made in one of two ways. In person, two phones exchange keys by scanning a code, which is the whole ceremony. Remotely, somebody you both already trust signs an introduction carrying the real keys, sent over channels that are already encrypted, so no invitation material ever passes through a third party's messaging app where it could be intercepted or forwarded to the wrong person.

2. Encryption, as it stands today

Messages are encrypted on your device and decrypted on the recipient's. Specifically, and as implemented now:

Each channel derives a shared secret by X25519 key agreement between the two parties' keys, passed through HKDF with a channel specific salt.
Message content is encrypted with AES-GCM, which provides confidentiality and integrity together, so a modified ciphertext fails to decrypt rather than decrypting to something else.
Every request to the relay is signed with Ed25519. The relay verifies the signature before acting, which is what makes an account a key rather than a login.
Private keys are generated on the device and never leave it. We have never held one and there is no mechanism by which we could.

Group messages use client side pairwise encryption: the sender encrypts the message once for each member, from the roster held on the device, and the relay carries opaque blobs it cannot correlate to content. A "group" send that does not cover every member is refused.

The honest limitation, stated before anyone asks

We do not have forward secrecy yet. Each channel's key is derived once, when the two of you connect, rather than being replaced after every message. Forward secrecy is the property that makes old messages unreadable even to somebody who later obtains today's key, because the key that encrypted them no longer exists. Signal's double ratchet is the standard way to do it, and it is named in our code as the production path.

Two things bound what its absence is worth to an attacker today. There is no archive here to go back through: the relay deletes a message when the recipient's device confirms it, and sweeps anything uncollected after three days. And whoever has taken a device's keys has usually taken the device, which holds the readable messages regardless.

Where it genuinely matters is an adversary able to record traffic over a long period and obtain long-term keys later, and the institution phase, where it stops being optional. It is the largest piece of unfinished security work, and we would rather you read it here than find it in somebody else's write-up.

3. The relay, and what it refuses to be

Our server exists to carry sealed material between phones that are rarely awake at the same time. It stores an encrypted blob, wakes the recipient's device, hands the blob over, and deletes it when the device confirms receipt. Anything never collected is swept after three days. That deletion is written as a database operation on the delivery path, rather than as a policy somebody has to remember to apply.

The relay has no read interface, and never will. There is no API that returns message content to anyone, including us. It is not an access control setting that could be changed by a future employee, an acquirer or an instruction: the content is encrypted to keys the server has never held.

Invitation codes, connection requests and detached media expire on the same principle: they are given a lifetime when written, and removed when it passes.

4. What the relay unavoidably knows

Any messaging service that delivers to a sleeping phone must know where to deliver. Ours knows:

Which anonymous account identifiers have a channel between them, and which belong to a group. This is a social graph. It links random strings to random strings, and it is the most sensitive thing we hold. It is also why names and photographs are never uploaded: a pseudonymous graph is one thing, and a graph with faces on it is another entirely.
That a message was queued, and when. Not its contents, its length in bytes rather than its meaning, and the identifiers at each end.
The IP address a device connects from, which is a property of the internet rather than a choice of ours.

We do not implement sealed sender today, so the relay sees both ends of each delivery rather than only the recipient. Push notifications add one more disclosure: to wake your phone, we ask Google's or Apple's push service to do it, and while the signal carries no content, the fact and timing of it are visible to them. Every messaging app on both platforms has this property.

5. Identity, and the absence of an anchor

An account is a keypair generated at install. No phone number, no email address, no username and no password, so there is no credential to phish, no SIM to swap, no password to reuse, and no account recovery question whose answer sits on somebody's social media page.

What this costs is stated in section 8. What it buys, besides privacy, is that entire categories of attack simply do not apply: SIM swap does not exist here as an attack, because there is no number to take over.

Your real name and photograph, which the app asks for so that people can recognise you, are stored on your device and shared encrypted with people you accept. They are never uploaded to us in any form. Nicknames you give people never leave your phone at all. One device holds an account at a time; moving to a new phone revokes the old one.

6. Groups grant one thing

Joining a group gives a member exactly one capability: posting in that group. It does not create a channel between them and any other member, does not reveal any contact detail, and cannot be used to add anyone onward. A person can sit in a group of forty and remain uncontactable by all of them. Group membership changes are visible to everyone in the group and are anchored to the roster held on each device rather than to the relay's word.

7. Losing the phone

With no anchor to re-prove, recovery is built from two mechanisms. A printed recovery key issued at signup, which is the path that needs nobody else, and shares of that same secret split among trusted contacts, where any two of four can bring the account back.

Both paths are deliberately slow and loud. A guardian assisted recovery is verified by a video call against the photo they hold, then held for 24 hours during which any guardian can freeze it. The printed key path is held for 72 hours, because paper carries no human judgement. Everyone who could object is told while the hold runs, and a frozen attempt discloses nothing, because the shares are destroyed unreleased. The old device is revoked when the recovery completes, never when it starts, so that "I lost my phone" cannot be used as a denial of service against somebody else's account.

8. What this design does not protect you from

A security page that lists only strengths is marketing. These are real:

Somebody you accepted. The closed network keeps strangers out. It does nothing about a person you let in, including a relative forwarding a scam link in good faith. Per channel controls that can block links or attachments exist for exactly this, and a link out of the app always says so before it opens.
A compromised phone. If the device is unlocked in someone else's hands, or has malware with sufficient privileges, encryption in transit is beside the point: the keys are in the platform keystore and the message history is on the same device, protected by the phone's own encryption rather than by a separate passphrase of ours.
Being talked into it. No software prevents somebody from being persuaded to approve something, to send money, or to accept a connection they should not. Holds, guardians and video checks raise the cost of that, and do not eliminate it.
Social recovery, honestly. Removing the phone number traded a technical attack, SIM swap, for a social one: convincing two relatives to approve a recovery. That trade is deliberate, and it is answered procedurally rather than mathematically, by the video check, the hold, the notifications and any single guardian's power to freeze.
Traffic analysis. Somebody observing our infrastructure learns who talks to whom and when, though not what is said. See section 4.

9. What is not built yet

As of 19 August 2026, and updated as each lands:

Forward secrecy. The double ratchet upgrade described in section 2.
Hardware backed keys. Generating the device key inside Android's StrongBox and Apple's Secure Enclave is the design and arrives with real device testing. Keys are held in platform secure storage until then.
Device attestation as the registration gate against bulk account creation, using Play Integrity and App Attest.
An independent security audit. None has been carried out. When one is, the report and our response will be published here, whatever it says.
The protocol specification. The full design will be published before public launch, so that it can be reviewed and so that nobody, including us, can later patent these mechanisms.

10. Reporting a vulnerability

If you find a flaw, write to [email protected]. We will acknowledge within three working days and keep you informed until it is fixed. We will not take legal action against research conducted in good faith that respects other people's privacy and does not degrade the service for anyone.

If you are comparing us with an established messenger: they have had years of scrutiny and we have not. The right way to read this page is as a description of what has been built and a list of what has not, rather than as a claim of equivalence.