Flamenet Messenger is an instant messenger that is end-to-end encrypted by default. For an encrypted conversation we hold no key that could decrypt you — the server is a dumb relay that shuttles sealed envelopes it cannot open. Turn encryption off for a conversation and it is stored on our servers instead, where we can read it. That choice is yours, per conversation.
Web client, live now · iOS app coming soon · Open AIM/ICQ bridge for the old crowd
What zero-knowledge actually means
Encryption is on by default, and while it is on this is not a privacy policy we are asking you to trust: the plaintext and your private keys never leave your device, and there is nothing on our side to hand over. 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. We use standard, well-analysed primitives — the same building
blocks the security community already trusts — instead of inventing our own.
To be clear about what that does and does not mean: the algorithms below are
long-established and heavily studied. This implementation of them has not been
independently audited. If you need software with a published third-party audit,
use Signal.
| 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
Not while the conversation is encrypted, which is the default whenever both of you have keys. For those the server only holds public keys and sealed envelopes; the keys that open anything live on your devices and are never uploaded, so there is nothing for us — or anyone who compels us — to hand over in readable form.
If you turn encryption off for a conversation, the honest answer is yes: those messages are stored on our servers, encrypted at rest with a key we hold, and an administrator can decrypt one to act on a verified abuse report. That is the trade for server-side search and previews, and it is why the switch sits in the conversation rather than in a settings page you will never find.
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.