Learn

On most messaging apps, your privacy rests on a company keeping a promise. The trouble is that a company can be hacked, bought, or handed a court order, and none of those things care what it promised. "We would never read your messages" is a statement about intent, and intent can change.

Pollis is built differently. Reading your messages is not something we choose not to do. It is something we are not able to do. Here is the plain map of who can see what.

Your device sees everything. That is where you type and read, so your messages are unscrambled there and nowhere else. The flip side: if someone gets into your unlocked device, they can read what is on it, and no clever maths can prevent that.

Our servers see the outside of the envelope, never the letter inside. They carry sealed messages we cannot open, because the keys to open them never leave your devices. What they can see is ordinary delivery information: that an account sent something, roughly when, roughly how big it was, and which conversation it belongs to. That is real information, and we would rather tell you about it than pretend it is not there.

Getting the right key to the right person is the part that takes care. Encryption only helps if the key your app uses really belongs to the person you meant. Safety numbers (Topic 6) and our public key logs (Topic 9) are what let you confirm that yourself, rather than take our word for it.

The pattern runs through everything here: we keep shrinking the list of things you have to take on trust, and we publish evidence for whatever is left.

Four words show up on every page that follows. None of them needs any maths to understand.

A key is just a very large number. Large enough that guessing it is not a matter of being patient, it is a matter of there not being enough time in the universe. When we say a key never leaves your device, we mean that number stays in your device's secure storage and is never sent to us.

Encryption is a lock that scrambles. Put your message in with a key and out comes noise. Put the noise back in with the right key and your message returns. With the wrong key you get nothing back, not a blurry version, not most of it. Nothing.

The clever part is that a key comes in two halves that are different from each other. One half is public and one is private. Anything locked with the public half can only be opened with the private half. So you can hand your public half to anyone, even publish it, while the private half stays on your device. Now anyone can send you something only you can open, and you never had to agree on a secret in advance.

Signatures are the same idea in reverse. Lock something with your private half and anyone holding your public half can confirm it really came from you and was not altered. Change a single character and the check fails. Pollis uses signatures constantly, so you can tell that a record genuinely came from the right place.

A hash is a fingerprint for data. Feed in anything, of any size, and get back a short string. The same input always gives the same fingerprint, and changing one character anywhere gives a completely different one. You cannot work backwards from the fingerprint to the original. That is what lets you say "this is exactly the file I meant" without publishing the file. When you see a long root code on our artifacts page, that is a hash.

Locking a message for one person is simple. Groups are where it gets interesting.

The obvious way is to encrypt the message separately for every member. Five people means four copies. A hundred people means ninety-nine copies of every message you send. It works, but it gets slow and expensive fast. And when someone leaves, everyone needs fresh keys, which means everyone coordinating with everyone.

Pollis uses a standard called MLS, short for Messaging Layer Security (RFC 9420, a published internet standard). It arranges the group as a tree.

Picture a pyramid. Every member is a box along the bottom. Boxes pair up into boxes above them, and so on up to a single box at the top. Each box holds a key, and the rule is simple: you know the keys on the straight line from your own box up to the top. The key at the very top is shared by everyone, and that is the key that protects the group's messages.

The payoff comes when something changes. Whoever makes the change only has to send one small update along their line to the top, and each part of the group can unlock the piece it needs from what it already knows. The work goes from one message per member down to about the height of the tree: roughly seven steps for a hundred people, not ninety-nine. For a thousand people, about ten.

Two words you will see throughout Pollis. An epoch is the group's version number; it ticks up every time the keys change. A commit is the update that makes it tick, such as adding someone or refreshing keys. Everyone has to apply commits in the same order, and keeping that order right across every device and reconnection is one of the hardest parts of building Pollis. It is also why every commit is written to a public log you can check (Topic 9).

To add you to a group, someone has to lock the group's current keys so that only you can open them, and they need to do it even while you are offline. So every Pollis device leaves a small locked box for itself in advance, called a key package. Think of a self-addressed lockbox at a front desk: anyone can drop something in, only you can open it. When someone adds you, they use that lockbox to seal up the group's current state and send you a welcome. You open it with your private half, and you are in.

Here is the part that surprises people. The welcome gives you the keys as they are right now. It does not give you the keys from before you joined, and it cannot, because the design deliberately makes new keys unable to reveal old ones. That is the same property that makes removing someone actually work.

So messages sent to a group before you joined are not readable by you. Not hidden by the app, genuinely unavailable. Every serious app built on this standard works the same way. It is the price of removal meaning something.

Leaving. When a member is removed, everyone else moves to fresh keys, and from that point on the departed device cannot read anything new. Whatever it already saw stays on it; we cannot reach into someone else's machine. Removal here is a property of the keys, not a setting on a server you have to trust.

Your own devices work the same way. Your phone and your laptop are separate members of the group, each with their own keys. Nothing is copied between them, because a key that travels is a key that can be stolen along the way. Adding your laptop is just like adding a person.

Which leads to the one sharp edge, stated plainly: a new device starts empty. There is no history backup. A new device joins from today forward. Your old messages live on your old device and nowhere else, not on our servers, which only ever held sealed envelopes, and not in a backup, because we do not make one.

We could offer one. The usual approach is to store your history on the server, protected by a PIN or passphrase. But that recreates the exact thing this app exists to avoid: a copy of your conversations sitting on our infrastructure, guarded by something short and guessable. So we do not do it. If you want your history on a new device, keep your old device. That is a real cost, and we would rather say so than hide it.

Suppose the worst has happened and someone lifts a key off your device today. What did they actually get? Two questions follow, one pointing backward in time and one pointing forward.

The past: forward secrecy. The answer is nothing. Keys only move forward, through a one-way step. Each new key is made from the previous one by a process that cannot be run in reverse, like mixing two paints and being unable to separate them again. Used keys are thrown away. So a key stolen today opens today's messages, and yesterday's are already out of reach, because the material that made them no longer exists anywhere.

One thing to be precise about: this protects the scrambled traffic, not your screen. If yesterday's messages are still on display in your app, someone holding your unlocked device can read them off the screen. The real guarantee is that someone who quietly recorded your encrypted traffic months ago still cannot open it, even with a key stolen today. That is a strong promise.

The future: post-compromise security. This is the less familiar and more surprising half. Normally a stolen key means you stay compromised until you notice and start over. Here, the group heals on its own. Every ordinary update, such as adding a member or a routine key refresh, replaces keys along part of the tree. As soon as a member the attacker does not control makes an update, the stolen key stops working, and nobody has to notice anything for that to happen.

This is why the tree from Topic 3 was worth the effort. Because rekeying is cheap, it happens often, and the more often it happens, the shorter the window in which a stolen key is any use. A stolen key is a window, not a door: it does not open backward, and it closes on its own.

Encryption protects your message. On its own, it does not tell you who is on the other end.

When you first message someone, your app fetches their public key from our servers. That is the one moment worth being careful about. If the wrong key were ever handed over, a message could be read in the middle, and both sides would still see a padlock, because the encryption itself is working perfectly, just on the wrong key. Every encrypted messenger has this same gap. Pollis closes it two ways.

First, safety numbers. Your app combines your key and your contact's key into a short code, shown as a set of digit blocks. Both of you compute the same code from the same pair of keys. If the keys ever differed, the codes would differ too. Compare them over any channel an eavesdropper cannot touch, by holding your phones side by side, reading them aloud on a call, or scanning a QR code, and a mismatch shows up immediately. Matching numbers mean you are talking to the key you think you are.

The catch is that this only helps if you actually compare, and most people never do. So there is a second safeguard that works even when nobody checks.

Second, every key we publish is public and permanent. Every identity key Pollis lists for an account is added to a public log that can only grow, never be quietly edited (Topic 9). Your own app keeps checking that the key the world sees for you matches the key you actually hold, and it warns you if they ever disagree. That means a substituted key could not stay hidden: it would sit in a public record for anyone to see, and your own device would flag it. You do not have to trust that promise; it follows from how the log is built.

Trust on first use. The first time you talk to someone, your app remembers their key. After that, a change is what gets flagged. Changes are usually innocent, like a new phone or a reinstall, so a flag is not an accusation, it is a nudge to re-check before you share anything sensitive. Pollis shows a shield next to verified contacts, and a distinct warning when a remembered key has changed.

In short: compare safety numbers once with the people who matter, and let the log handle the rest.

Suppose we publish a list, say every identity key we have ever issued, and promise to only ever add to it, never quietly edit or delete. How could you confirm that for yourself, without taking our word for it?

Downloading the whole list every day and comparing does not scale, and it only works if you never miss a day. The real answer is a structure called a Merkle tree, and once you see it, it is hard to unsee.

Start with hashes, the fingerprints from the last topic. Take your list of entries and hash each one. Take those hashes in pairs and hash each pair together, giving half as many. Pair those and hash again. Keep going until a single hash is left.

That final hash is the root. On our artifacts page right now it looks like this, a single fingerprint of the entire binaries log:

root: 37945cb2f61ee43782259a3893336b8ba8b8679d3af1612742deeec75e46cc0c

Here is the property that makes it worth the trouble: the root depends on every single entry. Change one character anywhere, and its hash changes, and so does its parent's, all the way up. The root becomes completely different. There is no way to alter an entry and keep the root the same, because that would need two different pieces of data with the same fingerprint, which is exactly what hash functions are built to prevent.

So the root is a fingerprint of the whole list, in sixty-four characters. That is the leverage. Instead of downloading a list that grows forever, you compare one short root. If you know the correct root, any claimed version of the list either matches or it does not.

You have a root: sixty-four characters standing in for an entire list. Two useful questions follow.

Is my entry actually in there? This is the inclusion proof. You do not need the whole list. You only need the fingerprints of the neighbours along the path from your entry up to the root. Hash your entry, combine it with the neighbour you were given, hash that, combine with the next neighbour, and keep climbing. If you land on the published root, your entry is in the tree. If you land on anything else, it is not.

For a list of a thousand entries, that is about ten hashes. For a million, about twenty. The proof grows very slowly: double the list, add one step. That is why this keeps working for logs that never stop growing.

Is this the same list as before, only longer? This is the consistency proof, and it is what makes "append-only" real. You saw a root last week and there is a new root today. A consistency proof is a small set of fingerprints showing that last week's list sits unchanged inside today's, with new entries only added on the end. If an old entry had been edited or removed, no such proof could exist. Append-only stops being a policy we state and becomes something you can confirm.

Who says which root is the real one? We sign it. Periodically we publish a signed statement, called a signed tree head, that ties together the root, the number of entries, a timestamp, and a signature over all of it. The signature uses one specific key, and the Pollis apps and the verifier tool carry that key's public half built in:

pinned key: 175ebfef98fc6b20c67c4cba9d4a36a4f85f05afa4e31f707e7d7e3c02227148

Building the key into the app matters. If the app simply downloaded the key from a server, a bad server could hand over its own key alongside a self-consistent fake list, and everything would appear to check out. Because the key is compiled in, a substituted key is spotted immediately.

One question remains: could different people be shown different lists? This is called equivocation, and it is the case the whole design is built to catch. Even a perfectly signed, append-only log could in principle show one clean list to auditors and a slightly different one to a single person, each internally consistent. The defence is refreshingly simple. Any two people who compare the signed heads they were shown will spot the difference at once, and because each head is signed, that difference is permanent, undeniable proof of a problem. Nobody has to trust anybody; they just have to compare. Our own publishing job checks what is actually being served for exactly this.

So the chain is: a root fingerprints the list, an inclusion proof puts your entry in it, a consistency proof stops it being rewritten, a signature under a built-in key says it is ours, and comparison between people stops two different versions being served.

Three separate append-only logs, one signing key, one public site at verify.pollis.com. Each is easiest to understand by the problem it protects against.

Log 1, account keys. It protects against the wrong person's key being used for you. Every identity key we list for an account goes in here, in order, with a version number. For a swapped key to be accepted, it would have to be published here, in public, in a record your own device audits. The rule is that versions only move forward, so an older key cannot be slipped back in and history cannot be renumbered.

Log 2, the message-order log. It protects against a group's history being quietly rewritten. A group moves forward in epochs, and everyone applies the same updates in the same order. That order is exactly what a bad server might try to reorder or split. So every update is logged, and the rule is that a conversation is a single straight line: each epoch appears once, and two different updates can never claim the same epoch. A split is refused when it is written.

Note what this log holds: sealed updates. Publishing them reveals the shape of a conversation, never its content. The server never had the keys, and neither does anyone reading the log.

Log 3, binaries. It protects against a special, tampered app being shipped to one person. The fingerprints of every released installer go in here. The rule is that the same release and platform cannot come to mean different files later. If a version were ever built for a single person, its fingerprint would either sit in a public log everyone can read, or be conspicuously missing from it. Either way it is detectable.

Why three logs and not one. A signed statement about one log must never be reusable as a statement about another. So each log signs under its own separate label, and a statement from one log fails to verify against another by design. Different questions, different logs, non-interchangeable proofs. They share one key and one site, which keeps the thing you have to trust down to a single built-in key.

Everything else on these pages assumes one thing: that the app running on your machine is the app whose source you can read. Nothing survives a tampered app, so this is the part to be most careful about.

Code signing, the check your operating system runs before letting an app start, proves less than people assume. An Apple or Windows signature proves that the holder of the company's signing key produced these exact bytes. It says nothing about what those bytes do. A tampered build that was still signed with the right key would pass every check your system makes.

So we publish the fingerprint of every release into a public log. The question stops being "did Pollis sign this?" and becomes "is this exact app the same one Pollis published to everyone, or a different one?"

Each release is recorded at three levels, because "the app" is not one file. The payload is the program and its resources before any signature; this is the level an independent person can rebuild from source and compare. The signed level is what you actually download, after Apple or Windows wraps it; signing deliberately mixes in unique data, so the signed file cannot be identical between two builds, by design. The installed program level records the fingerprint of the main program exactly as it sits on your machine, which is the one thing a running app can measure about itself. The app's built-in "verify this build" check compares the program you are running against that recorded fingerprint.

What this buys you. Suppose two people download the app. One gets the public build, whose fingerprint is in the log. If a different build were ever made for one person, its fingerprint would either be missing from the log, which that person's own app would notice, or present in the log, sitting in public next to the normal release for everyone to see. There is no quiet third option.

Reproducible builds, and where we actually are. A logged fingerprint proves we published these bytes. It does not by itself prove those bytes came from the source code you can read. Closing that gap needs reproducible builds, where anyone compiling the source at a given version gets a byte-for-byte identical result. That is hard, because ordinary builds bake in timestamps, file paths, and ordering that differ from machine to machine. Where we stand today:

Linux is reproducible. An independent rebuild, run from a public copy of the source with none of our secrets, produces the same fingerprint we logged. macOS and Windows are not there yet. This is the largest open gap in our verification story, and we would rather state it than gloss over it. The signing wrapper is never reproducible on any platform, by design.

There is also a second, independent record. Every release carries a build provenance record, stored in a public log that is not ours, proving which automated workflow produced the bytes, with no Pollis key involved in checking it. That answers a different question from reproducibility: provenance says who built it, reproducibility says whether it matches the source. Having both means a single compromised key does not undo the whole story.

Everything above explains what could be checked. This topic has you actually check it, on your own machine, in about two minutes. There are two ways in: reading the files directly, and running the verifier.

The verification data is just files. There is no clever service. verify.pollis.com serves a folder of plain JSON files, with no server-side logic and no database lookup, so nothing can behave differently depending on who is asking. That is deliberate: a service that computes an answer could compute a different answer for different people, while a folder of files written in advance cannot, and our daily job re-reads what is actually being served to confirm it matches what was signed.

/v1/<log>/sth/latest.json is the current signed statement; /v1/<log>/entries.json is the log's entries; /verify/release/<tag> is a ready-made report for one release. And /v1/<log>/public_key.json is the key the statements are signed with, which you should not simply trust: it is served for convenience, and the whole point (Topic 8) is that real verification compares it against a key you already have.

Fetch the current statement yourself, in any terminal, on any system:

curl -s https://verify.pollis.com/v1/binaries/sth/latest.json

The verifier does the actual checking. Reading the JSON tells you what is claimed. pollis-verify is a small standalone program that checks the claims: it re-hashes entries, rebuilds the tree, checks the proofs against the signed statement, checks the signature against a key built into the program, and re-runs the same rules the log enforces. It is the same checking code the app uses, not a separate version that might happen to agree by accident.

Four commands, four questions. Arguments come in this order:

# is the whole log consistent and append-only?
pollis-verify remote  https://verify.pollis.com

# what keys have we published for this user, in what order?
pollis-verify account https://verify.pollis.com <user-id>

# is this conversation's history a single unbroken line?
pollis-verify group   https://verify.pollis.com <conversation-id>

# are this release's files in the log, with valid proofs?
pollis-verify release https://verify.pollis.com v1.5.3

Here is a real run of that last command against the live log, captured 2026-07-23, not mocked up:

$ pollis-verify release https://verify.pollis.com v1.5.3

Release: v1.5.3
Found:   yes
STH:     tree_size 60  root 37945cb2f61ee43782259a3893336b8ba8b8679d3af1612742deeec75e46cc0c
Artifacts (publish order):
  darwin   aarch64  dmg       payload  payload 774c8f…ea92  artifact 774c8f…ea92  [included ✓]
  darwin   aarch64  dmg       signed   payload 774c8f…ea92  artifact eef7ae…c155  [included ✓]
  darwin   aarch64  dmg       exe      payload 774c8f…ea92  artifact 77fc24…bea5  [included ✓]
  windows  x86_64   nsis      payload  payload 88547f…7926  artifact 88547f…7926  [included ✓]
  windows  x86_64   nsis      signed   payload 88547f…7926  artifact 16edeb…e92b  [included ✓]
  windows  x86_64   nsis      exe      payload 88547f…7926  artifact 0f4c0f…73a6  [included ✓]
  linux    x86_64   appimage  payload  payload 9b1ab1…e653  artifact 9b1ab1…e653  [included ✓]
  linux    x86_64   deb       payload  payload 7f19ec…1a5a  artifact 7f19ec…1a5a  [included ✓]
  linux    x86_64   deb       exe      payload 7f19ec…1a5a  artifact 5d9281…55b5  [included ✓]
  linux    x86_64   rpm       payload  payload 586cfa…cbaa  artifact 586cfa…cbaa  [included ✓]
  linux    x86_64   rpm       exe      payload 586cfa…cbaa  artifact e45d0c…400b  [included ✓]

PASS: release binaries tree is valid

Read that against what you now know. tree_size 60 and the root are the signed statement from Topic 8, the same one the curl above returns. Each [included ✓] is a proof that actually checked out, a computation that succeeded on your machine, not a status someone typed in. The payload / signed / exe levels are from Topic 10. And PASS means the whole tree replayed cleanly under the built-in key, with every rule holding.

What a failure looks like. A FAIL is not necessarily a sign of an attack. It can simply mean the log is mid-rebuild, or that a release is newer than the last daily rebuild (Topic 9). The result that would genuinely matter is a valid signature over a tree that disagrees with one someone else was served, which is the two-versions case from Topic 8. That is why the most valuable thing you can do with this tool is compare results with someone else running it. That comparison is the whole basis of a transparency log.

Where it comes from. pollis-verify ships as a standalone program with checksums, and its built-in key is printed in the release notes. It is also buildable from source, and if you are seriously auditing us, build it, so you can read exactly what it does first. A verifier being open and rebuildable is what keeps it from being one more thing you have to take on trust.

By now you have every idea you need to read our public dashboards. Here is the tour, which is really just the key to the map.

On the website: the artifacts page. Latest releases shows the current version of each thing we ship, with download links.

Release proofs is the heart of it: for the current release, was it found in the binaries log, did the tree check out, and what is inside. You will see a row per file with the fields from Topic 10: platform, package, level, and two fingerprints, each with a tick. Read a tick as "a proof was checked", not "a box was ticked". The tree size and root are the signed statement from Topic 8, and the root is the same string you would get from the command line or the verifier tool. If a row says not in log yet, that is usually the daily rebuild (Topic 9), not a problem.

Daily transparency self-audit shows the current signed statement for all three logs, republished each day. And the one key you trust is the built-in signing key that everything above reduces to. The page also notes something worth reading: the key check it runs in your browser is a convenience, not the real safeguard. Real verification uses a key you obtained independently (Topic 11).

In the app: the Security page. This build gives you a version, a commit, and a verdict from the in-app check (Topic 10). There are four possible results. Build publicly verified means this exact app's fingerprint is in the public log for this release. Build publication pending means the release is not in the rebuilt log yet, which is normal right after a release. Verification unavailable means the check could not run, because the log was unreachable or this release predates the installed-program record; this is not an accusation. Build not in public log is the loud one: the release is published, a comparable fingerprint exists, and this one is not among them.

The difference between those last two is the difference between "could not check" and "checked, and something is wrong." It is worth keeping straight.

Below that, account key is your own device confirming that the key the world sees for you matches the key you hold (Topics 6 and 9), quiet when all is well. Devices and security events is a running record of enrollments and resets, worth a look if something feels off. And safety numbers per contact carry the shield states from Topic 6, including a distinct warning when a remembered key has changed.