Flamenet Messenger is an end-to-end encrypted instant messenger built on a zero-knowledge server. We never hold a key that could decrypt you — because we never have one. The server is a dumb relay that shuttles sealed envelopes it cannot open.
iOS · Android · Web · Open AIM/ICQ bridge for the old crowd
What zero-knowledge actually means
"Zero-knowledge" isn't a setting we could flip off, and it isn't a privacy policy we ask you to trust. The plaintext of your conversations and your private keys never leave your device. Here's the difference it makes.
How it works
Every device publishes a bundle of public keys to the directory. Senders use them to derive a shared secret without either party being online at the same time, then ratchet a fresh key for every single message.
Your device fetches your buddy's published prekey bundle and runs
Extended Triple Diffie-Hellman to derive a shared secret — asynchronously, even if they're
offline. The server only ever hands out public keys.
The Double Ratchet rolls a new encryption key forward for each message. A key recovered today can't decrypt yesterday's messages (forward secrecy) or tomorrow's (post-compromise security).
The message is sealed with AES-256-GCM and dropped into the server's
envelope queue as an opaque blob. The server delivers it without ever being able to open it.
Built in from day one
Security features that ship in v1 — not "on the roadmap."
Each device is its own encryption endpoint with its own long-term keys. A new phone is a fresh identity — no silent key handoff.
Compare a short fingerprint with your buddy to confirm there's no machine-in-the-middle. Get warned the moment a peer's key changes.
Every message gets its own key. Compromise one and the rest of the conversation stays sealed — past and future.
The server holds sealed envelopes only until delivery. There's no decryptable archive to breach, subpoena, or mine.
Talk to legacy OSCAR clients through an open bridge. Those threads are transport-encrypted and clearly badged as not end-to-end — no false promises.
We chose AES-256-GCM so the browser's native WebCrypto can do the math too. The web client is real end-to-end encryption, not a downgrade.
For the people who read the spec
No proprietary mystery box. Standard, audited primitives — the same building blocks the security community already trusts.
| Purpose | Algorithm | Notes |
|---|---|---|
| Key agreement | X25519 | Asynchronous X3DH handshake |
| Signatures | Ed25519 | Signs prekeys, anchors the safety number |
| Key derivation | HKDF-SHA256 | RFC 5869 |
| Message AEAD | AES-256-GCM | 12-byte nonce, 16-byte tag |
| Ratchet | Double Ratchet | Forward secrecy + post-compromise security |
| Server role | Relay + directory | Public keys & opaque ciphertext only — no escrow |
Questions
No. The server only ever holds your public keys and sealed ciphertext envelopes. The keys that decrypt anything live on your devices and are never uploaded. There is no escrow copy, so there's nothing for us — or anyone who compels us — to hand over in readable form.
It's gone — and that's the point. A new device is a brand-new identity with new keys; it can't read messages sent before it registered. We don't sync a decryptable history to the cloud, because doing so would defeat zero-knowledge.
Every device pair has a safety number derived from both identity keys. Compare it with your buddy once (in person, over a call, however you like) and you've verified the channel. If a peer's key ever changes, the app warns you before you keep talking.
Yes. We deliberately picked AES-256-GCM as the wire cipher so browsers can do the encryption natively with WebCrypto. The web client encrypts and decrypts locally, exactly like the mobile apps.
An optional open bridge lets you reach legacy OSCAR clients on the same buddy list. Be clear-eyed: those legacy networks can't do modern E2E, so those conversations are transport-encrypted and the app badges them as not end-to-end. Flamenet-to-Flamenet chats are always fully end-to-end.