you@mercury:~$

The security model, in plain text.

No diagrams that flatter us, no adjectives we haven't earned. This page says where plaintext exists, what our server can and cannot see, what cryptography is in the box, how to verify what you downloaded — and what is honestly not done yet.

cat TRUST_BOUNDARY.md

fig. 1 — the message path. plaintext exists only at the endpoints.

your device

Sealed at the source

Keys are generated locally and stored in the OS keychain. A message is encrypted before it touches the network — post-quantum hybrid for 1:1, MLS (RFC 9420) for groups.

──────▶ciphertext only
relay (untrusted)

A blind courier

Routes opaque bytes. Holds zero key material; no decrypt path exists. Runs at relay.mercury-messaging.com — or self-host your own.

──────▶ciphertext only
their device

Opened at the destination

Decrypted locally with keys that also never left their machine. Authenticity is confirmed by comparing safety numbers, human to human.

The operator of the relay — including us — is outside the trust boundary by construction. What the relay does handle is the routing metadata any courier needs: account identifiers, timestamps, ciphertext sizes, and connection metadata. It is not intended to receive plaintext message contents, and the client refuses to send any. The privacy page states this in full.

mercury --spec

what's actually in the box, v0.1.33. engineering posture: reviewed protocol libraries own the primitives; we own the policy around them.

encryptionEnd-to-end by default — there is no plaintext mode. 1:1 sessions use a post-quantum hybrid; group chat is real MLS (RFC 9420) running over verified 1:1 channels.
key_storageIdentity and session state live in an encrypted snapshot sealed by the OS keychain. Keys are never uploaded, never escrowed, never rendered in the clear by the UI.
identityA cryptographic account id (the hash of your identity key — self-authenticating). Shared via pairing code, username, or invite link; usernames are backed by the relay's key-transparency log, whose signed head the app pins. None of these change the trust model: the safety number is what proves you're talking to the real person.
local_dataConversations are stored in an encrypted local store on your device. Attachments (up to 4 MiB) are encrypted end-to-end and chunked.
backupsOptional encrypted backup export, key-derived with Argon2id. A backup is useless without your passphrase.
ai_participationBy design, an AI can only join as an explicit, visible, invited principal with scoped grants, end-to-end encrypted like any contact. There is no hidden plaintext path for AI — or for us.
policy_assuranceSecurity-critical decisions are mirrored into a deterministic validator layer — Helix, open source — and cross-checked against shared test vectors in CI, so the client and the policy spec can't silently drift apart.
updatesThe app checks a signed update manifest and prompts before installing — never silently. Installers are Authenticode-signed (Windows) with SHA-256 published for every artifact.

man verify-your-download

ten seconds of checking beats any amount of trusting. every release publishes a sha-256 next to its download.

LINUX

sha256sum

Put the .sha256 file next to the download and run
sha256sum -c Mercury-Linux-amd64.deb.sha256
Expect: OK. The .deb is unsigned (normal outside app stores) — the checksum is your verification.

WINDOWS

Get-FileHash + signature

In PowerShell: Get-FileHash .\Mercury-Setup-Windows-x64.exe and compare against the published .sha256. Then right-click → Properties → Digital Signatures: the installer is Authenticode-signed and timestamped.

UPDATES

Signed manifest

The in-app updater polls /updates/latest.json, accepts only releases signed with Mercury's update key, and always shows an install prompt. It never installs silently. Manual re-download from this site always works too.

docker run mercury-relay

You don't have to use our relay. Mercury ships pointed at relay.mercury-messaging.com, which only ever routes opaque ciphertext — but full independence is one Docker command away. Stand up your own relay, point Mercury at it in settings, and we are completely out of your loop.

Either way the math is the same: the relay holds no keys, so the relay reads nothing. Choosing ours is a convenience, not a trust decision.

cat KNOWN_LIMITS.md

disclosed, not buried. high-assurance claims must be earned — threat models, fuzzing, reproducible builds, third-party audits — and we name what's missing.

[WARN]

no independent audit yet. our crypto comes from reviewed libraries and our policy layer is cross-checked in ci — but until a third party audits mercury, this site will not use the word "audited". when it happens you'll see the report, not an adjective.

[WARN]

delivery requires a running process. real-time while mercury runs (tray included); a fully-quit app receives queued, still-encrypted messages at next launch. no OS push yet.

[WARN]

metadata is minimized, not zero. the relay must route, so it sees account ids, timestamps, and ciphertext sizes. we publish exactly what it processes on the privacy page.

[WARN]

built for small circles first. windows + linux today, macos and mobile on the roadmap. capacity and platform claims follow evidence, not precede it.

Found something? We want to know. Until a dedicated security contact is published, the open-source Helix repository on GitHub is the most reliable public channel to reach the project.

check us, then run us.