Artifacts & Proofs
Every public thing Pollis ships (desktop app, terminal client, verifier) and the append-only transparency-log proof that the bytes you download are the exact bytes we published.
pollis-verify command-line tool, or query the
public verification API directly (rate limits apply). Only the CLI gives you a
trustless verdict.
New to any of this? Learn: reading this page is the legend for the map, what a root is, what an inclusion tick actually means, and what green here does not prove.
Latest releases
The current version of each public output and where to get it. For the desktop app, the table shows every shipped installer and whether its bytes are provably committed to the public binaries transparency log.
Loading desktop release…
Loading release proofs…
Loading CLI release…
This is the tool auditors run to independently re-check everything on this page, trusting only the one
pinned key, with no server on the path. Prebuilt Linux and macOS binaries (with .sha256
files) ship on the pollis-verify-* releases, but building it from the open-source repo is the
stronger move, since a verifier we hand you is a verifier we could have tampered with.
-
cargo build -p verifiable-log-serve --bin pollis-verifyproduces./target/debug/pollis-verify
Daily transparency self-audit
Pollis publishes three separate append-only Merkle logs: the commit log (conversation history), account keys (published identity keys), and binaries (shipped release hashes). A scheduled job re-audits all three every day and republishes their signed tree heads. Those signed heads are what prove each log is append-only and fork-free (no rollback, no equivocation) trusting only the one pinned Ed25519 key. This displays the current published heads; it does not, and cannot, prove consistency in your browser, the verification docs and the transparency-publish workflow / run logs show how to check that yourself.
Loading signed tree heads…
The one key you trust
All of the above trusts exactly one thing: a single pinned Ed25519 public key. Every signature, on every tree head, on every release, is checked against it. If you trust this key, you can verify everything; if you don't, verify nothing.
Checking served key against the pinned constant…
The check above is the only verification your browser performs: it fetches the key the
server serves and compares it, character by character, to the constant baked into this page. Everything
else on this page is a server-computed verdict, re-run it with pollis-verify
to make it trustless.
WHAT AN AUDITOR RUNS
-
pollis-verify remote https://verify.pollis.comre-audit all three whole logs over HTTP -
pollis-verify release <tag> --base https://verify.pollis.comverify one release's shipped binaries are in the log -
pollis-verify group <conversation_id> --base https://verify.pollis.comverify one conversation's commit history is fork-free -
pollis-verify account <user_id> --base https://verify.pollis.comverify one user's published key history
VERIFICATION API
Base: https://verify.pollis.com. Example read endpoints anyone can fetch:
/v1/sth/latest.json, /v1/binaries/sth/latest.json, and
/verify/release/<tag>.
What these proofs do and don't say, precisely:
The binaries log and payload hashes prove the published bytes match and are committed to a public append-only log. That is not a claim that every platform is byte-for-byte reproducible from source. Linux payload reproduction is documented (reproducible-builds-residuals.md); macOS and Windows are published-bytes-match only.
The transparency logs prove no fork, no rollback, no equivocation of commit history and published keys and binaries, trusting only the one pinned Ed25519 key, nothing more. They do not prove the server behaves correctly in real time, and they are not anonymity.
The Delivery Service exposes no build or version endpoint by design (metadata minimization), so it isn't listed here. The browser on this page verifies nothing but the local pinned-key string match; treat every other verdict as server-computed until you re-check it with the CLI.