v2.3February 2026

Privacy Manifesto

Privacy is not an option we toggle on. It is the architecture. The protocol. The default. These are the five pillars Koto is built on.

Zero-Registration Identity

No phone. No email. No account.

Your identity is a 12-word seed phrase generated entirely on your device. We never ask for, store, or process any personally identifiable information.

›BIP-39 mnemonic generated from 128-bit entropy
›Ed25519 keypair derived locally — private key never leaves device
›Authentication via challenge-response, no passwords or OTP
›SHA-256 fingerprint as the sole user identifier

End-to-End by Default

Not optional. Not configurable. Always on.

Every message is encrypted with Signal Protocol (Double Ratchet + X3DH). Group chats use MLS (RFC 9420). The server stores only ciphertext it cannot decrypt.

›Signal Protocol for 1:1 chats — forward secrecy + break-in recovery
›MLS for groups — O(log n) key updates, scales to thousands
›Messages stored in ScyllaDB as opaque encrypted blobs
›Media encrypted client-side with AES-256-GCM before upload

ZKP Anti-Spam

Prove you're human without revealing who you are.

Zero-Knowledge Proofs (Groth16 via gnark) let you prove account legitimacy without exposing your identity. No CAPTCHA, no phone verification.

›New accounts complete Proof-of-Work (~5s CPU) at first message
›Anonymous credentials issued with 24h TTL
›ZK-proof verifiable in O(1) by the server
›Reputation is cryptographic — not tied to personal data

Sealed Sender

The server delivers — but doesn't know who sent it.

The sender's identity is encrypted inside the message envelope. The server routes by recipient ID only. Only the recipient can unseal the sender.

›ECIES on Curve25519 — sender fingerprint inside ciphertext
›Server sees only: recipient_id + encrypted blob size
›XChaCha20-Poly1305 for envelope encryption
›Metadata leakage reduced to near-zero

No Metadata

What we don't collect, we can't surrender.

IP addresses are hidden via OHTTP relays. No access logs, no analytics, no tracking pixels. Presence uses a pull model — we don't broadcast your status.

›OHTTP (RFC 9458) — relay sees IP, gateway sees request, neither sees both
›Three relay locations: EU, US, Asia — user chooses
›Lazy/Pull presence — status fetched on demand, never broadcast
›Zero server-side access logs for message content or metadata

Warrant Canary

Transparency report — cryptographically signed

Last updated: 2026-02-11

All clear

As of 2026-02-11, the Koto Messenger team makes the following statements:

✓We have NOT received any National Security Letters.
✓We have NOT received any court orders under seal.
✓We have NOT been subject to any gag order by any government.
✓We have NOT placed any backdoors in our software.
✓We have NOT provided any user data to any third party.
✓We have NOT been forced to modify our system to allow access or data collection.

PGP Signature

This canary is updated monthly. If this statement is not updated within 35 days, assume that one or more of the above statements may no longer be true. History of all canary updates is available in the public Git repository.