About Haven

Encrypted email services have long been recommended as the "good enough" answer — while quietly retaining metadata, depending on opaque business models, and asking users to "trust us." The metadata was always available. The business model was always "we make money somehow." The promise was always "trust us."

Haven exists because that answer ran out of room. This is a different one.

01. What Haven actually is

Haven is end-to-end encrypted email and private messaging built on a zero-knowledge architecture. That phrase gets overused, so here's what it means concretely: your messages are encrypted on your device before they leave it. The server receives ciphertext. It never has — and can never have — your decryption keys.

Email uses OpenPGP. Chat uses MLS (RFC 9420), the IETF messaging standard built for forward secrecy and post-compromise security. The server runs inside a Google Cloud Confidential VM with AMD SEV — hardware-level memory encryption that prevents even the infrastructure provider from reading RAM contents. Identity aliases let you receive email without exposing your real address. An encrypted vault stores sensitive files.

The whole system runs on infrastructure I control, in code I wrote, with keys only users hold.

02. Why Haven exists

Inside organizations, sensitive information travels further than intended. "Secure" systems leak metadata. Even well-intentioned services accumulate data they don't need and can't delete. The standard options — ProtonMail, Tutanota, Signal — are genuinely good products run by people who care.

But they're also companies with investors, jurisdictions, and business models that don't fully align with users. ProtonMail complied with a Swiss court order to log a user's IP. That's not a betrayal; it's a legal reality. But it illustrates that "trust us" has a ceiling.

Haven exists to remove that ceiling at the architectural level — to make compliance technically impossible for the things that matter most. Your email content. Your message history. Your encryption keys. Haven cannot hand those over because it never has them.

03. The technical approach

Client-side encryption only Keys are derived from your password using PBKDF2 and never leave your device. Auth tokens are separate from encryption keys.
MLS for forward secrecy Chat uses the MLS protocol (IETF RFC 9420). Each message ratchets the key state — a compromised session key cannot decrypt past messages.
Confidential VM hardware The server runs on Google Cloud's Confidential Computing with AMD SEV. RAM is encrypted at the hardware level — not accessible to the hypervisor or cloud provider.
Identity aliases Send and receive email from addresses that don't reveal who you are. Compartmentalize by context — work, personal, signups — without managing multiple accounts.

The stack is Flutter (cross-platform client), Python/Flask (API), Rust compiled to WebAssembly (PGP operations in-browser), and a Matrix bridge for federated messaging. Everything is open to audit — the architecture documents are public at havenmessenger.com/blog.

04. How Haven stays independent

Haven is an independent project — no investors, no VC funding, no board. Pricing is designed to cover infrastructure costs and sustain the project, not to optimize for growth metrics.

That independence has a practical implication: decisions here are made on technical merit and user privacy, not on what's easiest to monetize or most palatable to an acquirer. The history of privacy apps being acquired and quietly degraded (WhatsApp, Wickr, Skype) is a direct reason Haven is built the way it is.

Operator identity and jurisdiction are deliberately not published — a privacy product shouldn't hand adversaries a precise legal-pressure-point or doxxing handle. For security issues, contact us directly: ops@havenmessenger.com. Reports are taken seriously and responded to.

05. Available on Tor

Haven runs as a Tor v3 hidden service. If you reach us through Tor — using Tor Browser on the web or Orbot on Android — your IP address never touches Haven, never reaches our hosting provider, and never appears in any log we keep. There's no IP for us to log because none ever arrives.

And even without Tor, Haven doesn't keep your IP address: every server log truncates IPs (IPv4 to /24, IPv6 to /48) and we store no client IP tied to your account — across the app, encrypted chat, web, email, and federation. Rate limits are keyed to your account, not your IP. (This covers your own connection to Haven; email you receive still carries the sender's mail-server IP in its headers, as all email does.)

Web and API: haven4lifputq7xgqw4n5cnlivejcs55hpcuo3ah64abpfknqfen7aad.onion

Mail (IMAPS/SMTPS): bcidseufwgbowapakmrnrvjzj2boabzher4lqjfnjqld7iaezlczikyd.onion

Tor Browser users on havenmessenger.com see the .onion available badge in the address bar — clicking it routes you through the hidden service automatically. Android users with Orbot installed can enable Tor Mode in Haven's privacy settings.

06. The philosophy

Privacy isn't a feature. It's the load-bearing wall. When you compromise it for convenience or revenue, you're not making a privacy product with trade-offs — you're making a different product entirely.

Haven is opinionated about this. The zero-knowledge architecture isn't a selling point bolted onto a normal email service. It's the constraint everything else is built around. The PGP email implementation, the MLS chat protocol, the Confidential VM, the alias system — each one exists because it was required by the core premise: the server should not know what it doesn't need to know.

That's a harder product to build. It's a harder product to use. The encryption UX is genuinely less smooth than Gmail. But it's honest about what it is — and that honesty is the whole point.

Try Haven

Available on Android, Linux desktop, and web. Free to start — no credit card required.