Picture a sealed letter. Nobody on the way can read it, but the envelope still shows who wrote it and who it is for. Collect enough envelopes and you know who someone's doctor is, who they argue with at night, and which group they quietly joined. That is why people who study surveillance say metadata is the message.
Every messenger that encrypts end to end hides the letter. Far fewer hide the envelope. With E2EE v2, DChat hides the most telling part of it: the sender.
The short version
- Relays cannot read your messages. They are end-to-end encrypted with the Double Ratchet and MLS.
- Relays cannot see who sent them. Sealed sender puts your identity inside the encryption, where only the person you wrote to can see it.
- Relays see less of everything else too. Message sizes are padded, the message type is hidden, and times are rounded to the minute.
- It is checked to the byte. The seal matches the reference implementation byte for byte.
What a relay does
DChat has no central server. Messages travel through relays, service nodes run by independent operators who stake to take part. A relay's job is simple: take an encrypted message in, and hand it to the right person's devices, now or when they come back online. To do that job, a relay needs to know one thing: who the message is for. It does not need to know who it is from. Sealed sender makes sure it never does.
How sealed sender works
Your name goes inside the envelope
When you send a message, your app seals it to the keys of the other person's devices. Your account, your device and your identity are inside that seal, next to the encrypted message. Only the person you wrote to can open it. When they do, their app checks that the seal really comes from you before showing the message, so nobody can fake one in your name.
No login on the way in
Sealed messages go to the relay through a separate door that does not ask who you are. There is no account sign-in on that connection at all, so the relay has nothing to tie the message to.
Keeping spam out without names
A door without names could invite spam. DChat solves that with a delivery key. Each account has one, and it is shared only with the people that account talks to: its contacts and the members of its groups. Every sealed message carries a small proof made with the recipient's delivery key. The relay checks the proof and learns only that the message comes from one of the recipient's people, never which one.
Less to measure from the outside
Even a sealed message has a size and a time. DChat pads what is inside the seal to fixed steps, so a short "ok" and a long paragraph look the same size from outside. The kind of message and its disappearing-message settings are hidden inside the seal too, and the time a relay sees is rounded down to the minute.
What a relay handles, side by side
| Data | Can a relay see it? |
|---|---|
| What you wrote, sent or said | No, end-to-end encrypted |
| Which account sent the message | No, sealed sender |
| The kind of message and its expiry settings | No, inside the seal |
| The exact size | No, padded to fixed steps |
| The exact time | No, rounded to the minute |
| Who the message is for | Yes, so it can be delivered |
One seal for many devices
DChat ships the multi-recipient version of sealed sender: one message is sealed once for all of the recipient's devices, with a slot for each. We wrote it in DChat's own code and checked our output byte for byte against the reference implementation, the same way we checked the rest of E2EE v2. It also fits a decentralized network well: relays never need a list of every device of every account. Each of the recipient's devices simply tries the seal and opens the slot that is meant for it.
How it fits with the rest of E2EE v2
Sealed sender hides the envelope. The rest of E2EE v2 protects the letter: PQXDH and the Double Ratchet for one-to-one chats with a new key for every message, MLS for groups, and post-quantum key exchange in both, so messages recorded today stay closed even when quantum computers arrive. Together they mean a relay carries your conversations without reading them and without knowing they are yours.
The technical details are in the E2EE v2 whitepaper and the protocol specification.
