The simple version first.
The deep version one click down.

Haven uses hybrid post-quantum cryptography everywhere. Keys are agreed with X25519 + ML-KEM-768 (FIPS 203), everything is signed with Ed25519 + ML-DSA-65, content is sealed with AES-256-GCM, and keys are derived with HKDF-SHA256. "Hybrid" means an attacker has to break both the classical and the quantum-resistant half — so Haven is never weaker than today's best, and it resists "harvest-now, decrypt-later" capture.

Each circle has an epoch key distributed to its current members through that hybrid key exchange; every post is sealed under a key derived from it. Removing or blocking a member rotates the epoch and re-seals the new key to only the people who remain — so a removed member can't decrypt anything posted afterward. That's a math guarantee, not a server rule.

Full detail: GROUP-KEYING.md ↗

At Haven's heart is a single piece of trusted code — a Rust core (p2pcore) that handles your identity, the encryption, your circles, and the social engine (posts, stories, messages, reactions). Every app on every platform runs the same core, so your security never depends on which device you're holding.

Only the look-and-feel on top is native to each platform: SwiftUI on Apple and Jetpack Compose on Android reach the core through UniFFI; the Windows/Linux app (Tauri) links the Rust core directly, so it's a real network peer too, not a thin web page. Every client is a genuine peer on the network.

Full detail: ARCHITECTURE.md ↗. See exactly what's shipped where under availability below.

A path-selector walks a ladder: nearby (MultipeerConnectivity on Apple, Nearby Connections on Android — Bluetooth + local Wi-Fi) → direct (iroh QUIC with NAT hole-punching) → relay (only if nothing local reaches them). Above the transport, everything is opaque encrypted bytes — the transport is interchangeable and completely blind to content.

Finding a friend's current address uses signed records keyed by their public key, so a link to someone is permanent with no central directory to maintain. A link carries your account key, but devices are what actually get dialled, so each account also publishes its own device list in that same signed-record space — which is what lets two people who share no relay still find each other and hole-punch directly.

A relay stores and forwards only ciphertext. It cannot read content, contacts, keys, or notification text. As of the 2026-07 hardening it also enforces per-circle membership authorization: reading, writing and listing a circle's mailbox is served only to that circle's members, so a stranger who merely learns the relay's id can't fetch or enumerate a thing.

The honest limit — your IP address. To move your bytes, a relay briefly handles your IP, and it authenticates each peer by its node id (which is your public key) to enforce that membership check — so it does see IP ↔ node id in memory while it works. Haven's hardened defaults mean this is never logged and never persisted, and there's no account, name, or email in the system to tie it to. But it isn't invisible: a peer or a relay operator can see your IP. If that matters to you, run Haven behind a VPN or host your own relay. A built-in Tor/onion mode was evaluated and declined — Tor can't carry the UDP traffic Haven's calls and direct connections need.

Full detail: threat model and RELAY-AND-DEPLOY.md ↗

The in-app Mac relay runs a path router on 127.0.0.1:8675 that fronts the media store (:8674) and the DERP fabric (:3340) behind one origin, so a single tunnel — free trycloudflare, a custom Cloudflare domain, or any proxy you run — serves them all. A dedicated DERP URL is only for dual-hostname setups without the path router, e.g. https://derp.example.com → http://127.0.0.1:3340.

Full detail: CLOUDFLARE-TUNNEL.md ↗

GPS/EXIF location and identifying maker tags are stripped by default on capture, for photos and video (the video strip shipped 2026-07-15). Media is content-addressed with BLAKE3 and split into sealed chunks; because the address is the hash of the content, a relay swapping a blob is detected on verify. The camera pipeline calls no third-party SDK and logs nothing.

Full detail: MEDIA-AND-MUSIC.md ↗

Calls use WebRTC (DTLS-SRTP) for real-time audio/video and screen share. The call setup is sealed and signed end-to-end, so a forwarding relay can neither eavesdrop on a frame nor MITM the handshake. When two peers can't connect directly, a stateless connection relay forwards the encrypted stream without ever decrypting it.

Each device is authorized by a credential your long-term identity key signs into a device list, so adding or removing a device never changes who you are to your contacts. Your own devices self-sync additively, so a freshly-restored or empty device can never wipe content that exists elsewhere.

Be precise about revoking a device. Today a linked device holds a copy of your account seed, and revoking marks it revoked but doesn't invalidate the seed it already has. So revocation is a strong deterrent against a lost or stolen phone (its keychain intact, seed not extracted) — but it is not yet a cryptographic guarantee against a fully compromised one. The re-key that makes revocation cryptographic ("seed-drop") is designed and planned for release 1.0.7 — not yet shipped. Until then, the sure remedy against a genuinely compromised device is rolling a new identity.

Full detail: MULTI-DEVICE.md ↗