What we are building next
Published in advance, with the engineering reasoning, so you can hold us to it. Everything on this page is in development or planned. Nothing here is described as shipped.
Sealed sender In development
Every messenger carries routing information alongside the encrypted message so the network knows where to deliver it. The message body is unreadable, but the envelope around it still has to say something. Sealed sender removes the sender from that layer entirely.
The mechanism is an ephemeral key pair, generated fresh for every single message and tied to nothing. It wraps the whole envelope in a second layer that only the recipient's own key can open. A relay forwarding your message will see a value that looks random and changes every time, rather than an identifier that stays the same across everything you send.
The practical difference: today a node operator can see that the same account keeps sending. Afterwards, they cannot tell one sender from another.
Why our network can do this Architecture
This is not a feature we can simply copy from elsewhere, and it is not one every network can build.
DChat floods. Every node already holds every message, and your device drains what belongs to it. Delivery never required the network to know who sent a message, or even who it was for. Those fields are conveniences, not routing instructions, which is why they can be removed without touching how messages travel.
A network that assigns message storage by recipient address has the opposite problem. It has to know the destination to put the message in the right place. That is a structural constraint, not an oversight, and no amount of extra encryption removes it.
Encrypted routing tags Planned
The conversation identifier becomes a rotating tag derived from a secret only the two sides share, so it changes with every message and cannot be linked to the one before it. Your device precomputes the tags it expects and asks for those. The relay indexes an opaque value instead of a stable conversation id.
Optional private routing Planned
Onion routing hides where a message entered the network. It is a genuinely different protection from sealing the sender, and it costs real latency, which is why we intend to ship it as a per-conversation switch rather than a permanent tax on every message.
Turn it on for the conversations that need it. Keep full speed for the ones that do not. Messengers that route everything through extra hops by default are slower for every user, including the overwhelming majority who never needed it.
Independent security audit Planned
Our cryptographic specification is already published in full, down to key sizes, nonce lengths and derivation paths. That is the prerequisite for any audit worth having, and it is more than most messengers disclose at all. An external review is the next step, and we will publish the result whatever it says.
Want the parameter-level detail behind any of this? It is in the cryptographic specification. Questions, or want to hold us to a date? Talk to us.
Use it while we build the rest
No phone number, no email, no password. Free on Android, web and desktop.