Private, zero-knowledge messaging built for complete confidentiality.

No, and it is stronger than "not required": there is nowhere to put one. The sign-up form has no email field and the database has no column to hold one — users.email was dropped outright, along with every address already stored in it — and there is no phone number field either. "We do not have your email address" is a fact about the schema rather than a promise about our intentions, which is the version of that sentence worth anything.

The trade is the one that was always there: there is no password reset and there cannot be, because your private key is wrapped with your password and we have nothing to reset it against. An email address would never have changed that. What it would have done is give us one more identifier to lose or be made to hand over. Two things it does not buy you: your chosen username identifies you on Haven (so choose a pseudonymous handle rather than your real name), and connections connect transiently over TLS without persistent IP logging.

The server coordinates message routing between pseudonymous usernames in a room (not your real name, phone number, or contacts) and records message timestamps to preserve chronological thread ordering (without the server ever knowing what the message said). We cannot read a single word of your messages, view any media attachments, or eavesdrop on call streams — all contents are encrypted client-side before leaving your browser. Furthermore, Haven maintains zero persistent IP address logs.

Partly, if you go and turn it on. There is an optional per-message ratchet, off by default: switched on for a conversation, every message gets its own key, your device destroys each message key 90 days after first reading or sending it and each superseded conversation key after its grace period, and while it is on only text can be sent and messages cannot be edited. It is a hash ratchet, not a Double Ratchet, so it does not heal after a key is stolen, and it does nothing about the copies the server keeps. Those are the other half: a conversation key that rotates on a schedule, and a setting — per conversation, off by default, off for every conversation that already existed — that tells the server to delete your wrapped copy of each superseded key after a grace period. Leave it off and the server keeps every historical key, wrapped to your long-term identity key, so an adversary who takes the database and later cracks your password gets everything you have ever sent rather than a window. Turn it on and the window is roughly five weeks, depending on regular key rotations and participant settings. Signal, Wire and WhatsApp implement double ratchet protocols by default, which prioritize immediate forward secrecy at the cost of requiring mobile device pairing and phone numbers. Haven's architecture is optimized for web and desktop flexibility, scheduled session key rotation, and client-controlled message lifecycles. The threat model states every detail of ours.

No. Message bodies, file contents, filenames and new group names arrive already encrypted, and the keys we hold are wrapped under passwords we never see. The honest caveat is the one at the top of this page: we serve you the JavaScript that does the encrypting, so a compromised or compelled server could serve a modified copy of it to one targeted person, and that person could not tell. That is a property of every browser-delivered encrypted app, ours and everyone else's, and it is the thing to weigh before trusting any of us.

After 90 days, the server deletes its copy of a message. That's a cost limit, not a privacy feature dressed up as one, and it works by the same mechanism as disappearing messages — with the same caveat that applies to every disappearing-message feature in every app: it cannot reach into a device that already synced the plaintext and remove the copy sitting there. Paid plans keep the server's copy until you delete it.

You lose the account. Your private key is wrapped with your password, so there is nothing for us to reset it against — a reset link would mean we held a way in, which would defeat the point. There is also nowhere for a reset to be sent: accounts hold no email address, because the column that used to hold one has been dropped from the database. Encrypted backup and restore exists, under a separate passphrase of your choosing, and lose that one and the backup is gone too.

No. No analytics, no cookies, no third-party scripts, no embedded fonts fetched from anyone else's server, no pixel in the footer. The only thing this site stores is your light/dark preference, in your own browser. For a privacy product, a tracker here would be self-defeating.

Yes, and it is unsupported. The source is all here and readable, and an instance you deploy runs the same code we do — but it is not the product we sell. No support, no managed upgrades, no SLA, and the backups, TLS, patching and disk space are yours. The plan limits still apply, because they come from the same catalogue the code enforces, and every account on a fresh install starts on Free — including its 90-day sweep of the server's copy of messages. Haven serves an Onion-Location header, so an instance you publish as a Tor onion service advertises itself and Tor Browser will move readers to it — which is the only way to keep client IP addresses away from the server.

What changes on the trust side is worth being precise about: it doesn't remove the problem of trusting whoever serves the JavaScript, it moves that problem onto you. Hosted Haven asks you to trust an operator; running it yourself asks you to be one. Running a server well is a real skill, and for most people that swap is the worse trade rather than the better one.

Yes, for up to six people in a group conversation, voice or video. Six is a deliberate limit: every participant connects to every other, which keeps the call end-to-end encrypted with no media server, and costs upload bandwidth that grows with each person. Calls have what you would expect — raised hands, reactions, speaker view, screen sharing, a waiting room for locked calls, captions and background blur — and the hands, reactions and captions travel inside the encrypted call, never through our server.

Yes, with a prepaid voucher code, and that is the only way. A card ties your legal identity, your billing address and your bank to a Haven username, and for the threat model this site describes that invoice is a serious deanonymiser — more useful to an adversary than the ciphertext they cannot read.

A voucher is a 24-character code that buys a set number of months on a set plan. You ask us for one, we agree how you are paying — cash, a bank transfer, Monero, a reseller who never tells us who you are — and you redeem the code in the app. Redeeming it contacts no payment processor, creates no customer record, and asks for no address. This website cannot sell you one on the spot and does not pretend to; a person mints it and sends it the way you asked.

The limit, because a claim with no limits stated is worth nothing. One column records that your account redeemed that code — the server has to know whether a code has been spent — and it is on your own data panel rather than hidden. So the unlinkability is between Haven and you, and it holds only if the code changed hands somewhere we cannot see. Buy a voucher from us by card in your own name and we can join both ends ourselves. The pricing page says all of this in full.

No, and we could not if we wanted to: no account holds an email address, because the column that used to hold one was dropped from the database. There is no receipt from us, no renewal reminder, no card-expiring warning and no notice before a plan lapses. Stripe may send a receipt to the address you typed on Stripe's page — that is Stripe's message and Stripe's record. We do not send it and we cannot. We do hold that address, though, if you paid by card: Stripe's notifications are stored here exactly as they arrive so their signatures stay checkable, and a card payment's notification carries what you typed on Stripe's page. This paragraph said otherwise until an audit of the schema caught it.

The account page in the app is where the state of your subscription lives. If a card expires, nothing reaches you: the plan goes past due and free limits apply to new activity until it is settled, and nothing is deleted. Exactly what does and does not happen then is on the refunds page.