Skip to content

What is end-to-end encrypted

The app shows E2EE ready when its encryption self-test passes on your device. This page explains what that covers and what it does not. It is written to be accurate rather than reassuring: where ZippChat falls short of the strict meaning of end-to-end encryption, it says so.

What end-to-end encryption means

A message is end-to-end encrypted when it is encrypted on the sender's device with keys that only the intended recipients' devices hold. Servers in between store and forward it, but cannot read it — not the people running them, not an attacker who breaks into them, and not anyone who compels the operator to hand data over.

Two things follow from that definition and matter below:

  • It only covers content. To deliver a message, a server has to know who it is for and when it was sent. That metadata is not end-to-end encrypted in ZippChat, or in most messengers.
  • It depends on who hands out the keys. If the server decides which devices receive a key, a dishonest server could add a device of its own. The defence is letting people check each other's keys, which ZippChat offers for direct messages but not yet for channels.

At a glance

What End-to-end encrypted? Who could read it
Direct messages Yes Only the devices in the conversation
Messages in secure channels (the default) Yes, with a caveat about key distribution Members' devices
Attachments in secure channels Yes Members' devices
Messages in persistent channels No — server-held key Members, and the server operator
Attachments in persistent channels No — server-held key Members, and the server operator
Avatars, banners, server icons No Anyone who can see them, and the operator
Voice calls Not against the operator — hidden from the media relay only Participants, and the server operator
Reactions, names, membership, voice presence and other metadata No The server operator
Push notifications Carry no content at all —

"The server operator" means ZippChat on the main service, and whoever runs a self-hosted instance on theirs. See the hosting model for why that difference matters.

Direct messages

DMs use the X3DH key agreement and the Double Ratchet, the design Signal published, over libsodium:

  • Every device you sign in on has its own identity key, generated on the device and never sent anywhere except inside your encrypted PIN backup.
  • Starting a conversation combines your keys with keys the other person's device published in advance, so it works while they are offline.
  • Every message moves the ratchet forward. A key that leaks today does not unlock past messages, and the conversation recovers from a compromise once both sides send again.
  • Each of the other person's devices — and each of your own other devices — gets its own encrypted copy.

Check your safety numbers. Each DM shows a 60-digit safety number for each pair of devices. If it matches what the other person sees on their device, nobody — including the server — has slipped a key into the conversation. The app remembers a key the first time it sees it and refuses to send if that key later changes.

Specification: E2EE protocol, with the exact parameters in the spec errata.

Secure channels — the default

Every new channel is secure unless whoever creates it chooses otherwise.

  • Messages and attachments are encrypted on your device with the channel's current key, which only members' devices hold. The server stores ciphertext; moderators cannot decrypt it, and abuse handling relies on members reporting what they can see, as on Signal.
  • The key rolls. When membership changes, a member's client creates a new key and encrypts it separately for every member's device. Each new key is called an epoch.

Be aware of three limits:

  • The server's device list is trusted. A channel key is encrypted to every device the server lists for each member. Unlike in DMs, there is no safety number for channel members yet, so a dishonest or compromised server could add a device of its own and receive future channel keys without anyone noticing. Secure channels therefore protect you against a server that is breached or compelled to hand over its stored data. They do not protect you against a server that is actively rewritten to attack you.
  • Rotation is done by members, not the server. A new key is created when a member's client is online to create it. Between a membership change and that rotation, the previous key stays in use — so someone who joins can read messages sent since the last rotation, and someone who leaves can read what is sent until the next.
  • Encryption is per server, not per channel. A secure channel's key goes to the devices of the server's members. Channel permissions decide what the server lets each member fetch; they are not a cryptographic boundary.

Specification: encryption modes.

Persistent channels — not end-to-end encrypted

A channel can be created as persistent instead. Its key is held by the server, in a key vault, and handed to members' devices when they need it. Messages are still encrypted on the device and stored as ciphertext, but the server can decrypt them, and so can anyone who obtains the vault's keys, lawfully or not.

That trade-off buys things a secure channel cannot have: full history for anyone who joins later, and moderators who can read reported messages. A server administrator's decrypt is written to the server's audit log before any plaintext is returned, and refused if the log write fails.

On the main service this means ZippChat can be compelled to produce the plaintext of persistent channels. That is why it is not the default.

Attachments

Files you attach are encrypted on your device before upload, with a fresh key per file, wrapped with the channel's key. Thumbnails are made on your device and encrypted the same way.

  • In a secure channel or a DM, attachments are end-to-end encrypted like the messages.
  • In a persistent channel, the server holds the channel key, so it can decrypt attachments too.
  • Avatars, profile banners and server icons are encrypted by the server rather than your device, so the server can read them. They are meant to be seen.

The server still sees each attachment's file name, type, size, upload time and channel, and a SHA-256 fingerprint of the original file, which it uses to check reports of illegal content. A fingerprint lets the server confirm whether a file is one it already has a copy of; it does not reveal a file it has never seen.

Voice — protected from the relay, not from the operator

Voice calls go through a media relay (an SFU, LiveKit). Every audio frame is encrypted before it leaves your device with the channel's room key, so the relay forwards audio it cannot hear, and the app refuses to join a call when that encryption is not set up.

But the room key is created and stored by the ZippChat server, and handed to any member allowed to connect to the channel. That means the operator of the server can obtain it. Voice is therefore not end-to-end encrypted in the sense used on this page: it protects calls from the relay and from anyone tapping the network, not from the operator. The same key is used for the whole of a call and is replaced when the call's room closes, not when someone leaves.

The server also knows who is in which voice channel, when they joined, and whether they have muted or deafened themselves — the app shows that state to other people, so the server stores and relays it. The relay sees each participant's account id, their IP address and when they speak.

What the server always sees

For every channel mode, including secure channels and DMs, the server knows:

  • Accounts and profiles — usernames, display names, email, bio, status text, avatars, per-server nicknames.
  • Server structure — server names, descriptions and icons; channel names, topics and categories; roles, permissions, invites, bans and their reasons.
  • Relationships — who is a member of which server and since when; friendships; blocks.
  • Message metadata — who sent each message, in which channel or DM, when, whether it was edited or deleted, which message it replies to, and its length (messages are not padded).
  • Reactions — which emoji, from whom, on which message. They are not encrypted.
  • Pins and who pinned them.
  • Activity — when you are online, when you are typing and where, and how far you have read in each channel.
  • Voice presence — as above.
  • Key bookkeeping — which of your devices exist, and which channel keys each device has been given.
  • Network data — your IP address, as every server you connect to does.

Mentions travel inside the encrypted message, so the server does not learn whom you mention.

Push notifications

A push notification never contains a message. The server sends a wake-up carrying only {"v":"1","t":"wake"}; your phone then fetches and decrypts new messages itself and decides what to show. Through Firebase Cloud Messaging, Google sees that a wake-up was sent, when, and whether it was urgent (a DM is). UnifiedPush wakes can additionally be encrypted to your device.

Specification: push notifications.

Your PIN backup

So that a new device can recover your identity, your keys can be backed up encrypted under an 8-digit PIN. The PIN is stretched with Argon2id and the backup is encrypted with AES-256-GCM on your device; the server stores only the result.

The PIN is short, and there is no secure hardware enforcing a guess limit. So the backup is only as strong as an 8-digit PIN against someone who holds a copy of the server's data. The backup contains your keys, not your message history.

On a self-hosted instance

Everything above holds on any instance, with one change: the operator is whoever runs that box. Persistent channels, voice keys and metadata are visible to them instead of to ZippChat.

Read further