I spent a long time recommending encrypted email services to people while knowing, in the back of my mind, that those services still knew who I was sending to, when, and how often. The metadata was always available. The business model was always "we make money somehow." The promise was "trust us."
I got tired of that answer. So I built a different one.
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.
I've worked in IT at a director and VP level. I've watched what happens to sensitive information inside organizations — how it travels further than intended, how "secure" systems leak metadata, how 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.
I wanted a system where that ceiling doesn't exist because the architecture makes 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.
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.
My name is Jason Bolduc. I'm a software developer and IT director based in British Columbia, Canada. Haven is an independent project — no investors, no VC funding, no board. The pricing is designed to cover infrastructure costs and allow me to keep building, 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.
If you find a security issue, I want to hear about it directly: ops@havenmessenger.com. No bug bounty program yet — that's honest — but I take reports seriously and respond.
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.
Available on Android, Linux desktop, and web. Free to start — no credit card required.