A plain-language guide to what end-to-end encryption protects, what it doesn't, and what that means for you.
In a normal chat system, your messages travel through a server in readable form. The server — and anyone who operates or compromises it — can read everything. End-to-end encryption (E2EE) changes that: your message is encrypted on your device before it leaves, and can only be decrypted on the recipient's device. The server in the middle sees scrambled data it cannot read.
This server uses OMEMO, the end-to-end encryption standard for XMPP. When you log in on a trusted device, your client generates a unique keypair: a private key that never leaves your device, and a public key that gets uploaded to the server. Other users' clients download your public key and use it to encrypt messages addressed to you — messages that only your private key can unlock.
This happens automatically. You can tell a conversation is encrypted by the lock icon at the bottom of the chat: a closed green lock means OMEMO is active. An open lock means the conversation is not encrypted. Encryption is enabled by default when you select This is a trusted device at login.
Each device has its own private key. When you add a new device, it generates a fresh keypair and uploads the public key. Other clients then download it — but messages sent before that download cannot be decrypted by the new device. There is no way to retroactively decrypt older messages on a new device.
On the other side, your chat partner may see a notification that a new device has appeared on your account. This is a deliberate security feature — it alerts them that someone new could be reading the conversation going forward.
OMEMO can work in group chats, but with significant caveats. For a group chat to be encrypted, it must be set to members-only, and every single member must be using an OMEMO-capable client. Key distribution gets more complex as the group grows — every member's client must have the public keys of every other member's every device.
Encrypted group chats are best kept small and used for genuinely confidential discussions. Large public rooms that allow anyone to join from any server generally don't use OMEMO — and that's fine, since everyone in the room already has a copy of the conversation by definition.
Key distribution lag is more pronounced in group chats, especially across federated servers. When someone adds a new device or switches clients mid-conversation, there may be a brief period where some members see undecryptable messages until keys have been distributed to everyone.
End-to-end encryption secures your messages in transit. Once they arrive and are decrypted on your device, they are only as secure as the device itself.
Physical and account access:
Private/incognito mode:
Using private or incognito mode means the browser wipes its local database when the window closes, so no chat history is left on the device afterward. However, this comes with real trade-offs: you would need to export a backup before closing every session if you want to keep your history, and import it again at the start of the next session. You also risk losing your session entirely if the browser crashes before you can export. It's a reasonable option for shared computers, but inconvenient for daily use.
Backup files:
If you export a message backup, that file contains your full chat history in plain text as well as your OMEMO identity keys. Treat it like any other sensitive document — store it somewhere secure.
The other end:
Even if you delete your copy of a conversation, you have no control over what the other person does with theirs. This is true of all instant messaging systems — even apps that claim to delete messages can't prevent someone from photographing their screen or using other means to preserve what they saw. E2EE ensures the server can't read your messages; it doesn't guarantee the conversation stays private forever.
This chat runs in your browser. That's convenient, but it comes with a few limitations compared to a dedicated XMPP app: