Most encrypted messengers solve the privacy problem but create a new one: they still need to know who you are. Phone number for Signal. Email for ProtonMail. Account on someone's server for Matrix.
I wanted to see if you could have genuine E2E encryption with nobody knowing who you are — not even at signup.
The result: WRTC — open the browser, you're instantly a node on the network.
How identity works without accounts
When you first open the app, the browser generates a NaCl keypair (Curve25519 + XSalsa20-Poly1305) entirely client-side. Your "address" is the base58-encoded public key — something like
wmail://8S4WzU1KJA...
. No server ever sees your private key.
Backup is a BIP39 12-word seed phrase. That's the whole "account" — 12 words.
How messages are delivered
Since there's no central user directory, I built a relay server that:
- Accepts encrypted message blobs addressed to a public key
- Holds them until the recipient connects
- Delivers and deletes — no persistence
The relay never sees plaintext. It just shuffles ciphertext boxes from pubkey A to pubkey B.
The invite flow
The UX problem with "no accounts": how does someone find you?
Answer: invite links. Your address becomes a shareable URL:
wrtc.app/app?chat=wmail://yourpubkey
. Someone taps it, their keypair generates, and they're immediately in a chat with you — pre-filled with an intro message. Zero friction.
Voice & video
WebRTC P2P calls, signaled through the relay. The relay passes the SDP offer/answer, then gets out of the way — actual media never touches the server.
What's next
• Named identities (
.wrtc
names, optional)
• Group chats
• Self-hosted relay one-liner
Repo + live demo: wrtc.app
Curious what the dev community thinks — especially the "is a relay-based model actually private enough?" question.
Top comments (1)
"doesn't require a username"
asks to register a username