Your friends and your family. That's the whole product.
A peer-to-peer, end-to-end encrypted social network for the people you actually know — photos, video, music, messages, and calls shared inside small circles of friends and family. No central server holds your content. No phone number or email. No tracking. No ads. No doomscroll.
Think iMessage + Apple Photos + Apple Music as a private social network — without the ads, the surveillance, or the infinite feed. The maker runs no servers and pays nothing monthly; your media rides on a Haven relay you (or a friend) run, your own S3-compatible bucket, or a direct peer-to-peer link.
- No surveillance, zero operator cost. There is no server that ever sees your
plaintext or any personal data — and nothing the maker has to pay for monthly.
Media rides on a Haven relay you run (any official app, or the tiny
haven-relayon a Pi/server) or your own S3-compatible bucket (S3/R2/B2) — nothing else, nothing of ours. Peer connections use free, swappable, community/public relays only as a last-resort encrypted pipe. The app is free — no ads, no tracking, no subscription, no in-app purchases — so bring your friends and build your circles. It stays free of ads because there are no servers to pay for, and because the people who find it valuable fund development directly. - Quantum-safe by default. Every content key is derived from a hybrid of classical (X25519) and post-quantum (ML-KEM-768) key exchange, and every signature is hybrid Ed25519 + ML-DSA-65 — so stored ciphertext is protected against "harvest-now, decrypt-later" attacks.
- Seedless device linking (1.0.7). A device you link no longer has to hold a copy of your account master seed: it runs on per-device keys with an account-signed credential, so revoking it can cut it off cryptographically — from circle content and your account-state channel — not just advisorily. The seed concentrates on one primary device plus your encrypted iCloud-Keychain escrow. This rolls out per-circle, automatically, as everyone updates (see Status).
- No PII. An account is just a keypair generated on-device. You're reachable by a permanent link or QR — no phone, no email, ever.
- Local-first transport. Traffic prefers Bluetooth, then local/peer-to-peer WiFi, and only falls back to a relay when there's no closer path.
- You're in control. Block anyone, approve every new contact, and on-device sensitive-content guards keep flagged media blurred — all without anything leaving your phone.
1.8.3 is live on the App Store for iPhone and iPad
(https://apps.apple.com/app/id6782147901 — the Mac build of 1.8.3 is in review; 1.8.1 is what's
live on the Mac today). 1.8.x is the delivery-and-responsiveness stretch: offline friend invites
(add someone while their app is closed), authored posts and reactions that retry until they land
instead of waiting for the author to relaunch, a feed that stopped re-decoding its own thumbnails,
and a launch/foreground freeze chased stack by stack until the main thread no longer waits on the
engine at all — see CHANGELOG.md)
and Windows is live on the Microsoft Store
(https://apps.microsoft.com/store/detail/9NKTFH1MF4LM).
Android is live on Google Play
(https://play.google.com/store/apps/details?id=com.blaineam.haven);
neither the Windows nor Android GUI app is on GitHub Releases
anymore. The Linux installers and
the haven-relay daemon still ship on GitHub Releases (free). Per the
channel policy, each platform ships through its own store and
GitHub Releases carry only the storeless Linux + relay builds — so you download
the free iPhone/Mac/Android/Windows app from its store, never from a release tarball. It's been used device-to-device over the real internet and a
nearby Bluetooth/Wi-Fi mesh daily. Done so far:
- Hybrid post-quantum core (
haven-p2p) — identity (Ed25519+ML-DSA, X25519+ML-KEM-768), AEAD seal/open, reach-me links, deterministic seed-based identity; unit-tested. - Real P2P transport — sealed posts, DMs, reactions, comments, and media move peer-to-peer over iroh QUIC (with a nearby Bluetooth/Wi-Fi mesh fallback and a ttl-bounded mesh-relay), decrypted byte-identical.
- Group keying (sender keys + epochs) — posts and DMs are sealed under a rotating
per-circle epoch key distributed via the hybrid KEM. Removing or blocking a member
(a contact who never held your seed) rotates the epoch so they can't decrypt content
posted after — this member removal is cryptographic, not advisory. The epoch also
rotates on a 7-day periodic schedule (driven by the sync bundle in core), so a quiet
circle still gets bounded forward secrecy. See
docs/GROUP-KEYING.mdanddocs/SECURITY.md. - Seed-drop — cryptographic device revocation (1.0.7, D16 Phase 2 · S2–S5 core). Day-to-day
operation is re-rooted on per-device keys with account-signed credentials; a device linked
through the new seedless flow never receives the master seed, and revoking a device can
cut it off cryptographically — excluded from the next key commit and re-keyed out of the
account-state channel — with a seedless device unable to forge a roster to re-add itself. It
activates per-circle once every member's devices advertise capability (all-present-positive,
never inferred from absence); until then a dual-seal coexistence path keeps un-upgraded peers
fully working. See
docs/SEED-DROP-DESIGN.md. - MLS-style group encryption — TreeKEM on our own PQ primitives (1.0.7, enabled for owner-verified circles). A
ratchet-tree group layer adding post-compromise security, a forward-secrecy deletion discipline,
and per-message forward secrecy for DMs, reusing Haven's existing hybrid primitives. It is
MLS-shaped, not RFC-9420 wire-interoperable (every ratified MLS ciphersuite is classical;
interop would regress the PQ posture). It is enabled in 1.0.7 for circles with a verified
owner — circles created from 1.0.7 on, whose id is cryptographically bound to their creator.
Circles you already have do not get it automatically: they have no owner (nothing recorded who
created them), and an owner can't be added after the fact in a way other members could trust, so
they keep the encryption they already have — which still cuts off someone you remove. To carry an
older circle across, whoever made it offers an upgrade and each member taps once to follow
it; the app shows who's asking, because no signature can prove someone created a circle that
never recorded an owner — that's a judgement only a person can make. Even on an owned circle it
activates only once every member's devices have updated and joined (an all-present/all-joined
gate); until then the circle stays on the existing key path (byte-identical to 1.0.6), and a device
that falls behind reverts its circles to that legacy path within one sync — no one is ever
stranded, and it only ever changes which key seals content, never whether content is
encrypted. Its audit to date is
an internal, AI-driven adversarial code review — 0 critical / 0 high — a
strong first pass, not a formal external audit. There is no paid external audit, and none is
planned — Haven is free and unfunded. Independent review is welcome from anyone: report findings
privately to apps@wemiller.com and they will be fixed before disclosure, with credit by name to
whoever reported them. See
docs/TREEKEM-DESIGN.md. - Own-device sync that converges — a user's own iPhone/iPad/Mac share the account
identity but take per-device transport identities, and their divergent per-device
epoch keys now deterministically converge (both devices adopt the numerically-larger
key + circle secret), so posts and DMs authored — or received — on one device show up
on the others. See
docs/MULTI-DEVICE.md. - Security-audit hardening (2026-07) — the HTTP relay now requires a signed auth
header (not a bearer token) and authorizes per-circle membership, failing closed;
devroster writes are verified. WebRTC call signaling is sealed + signed, so a relay
in the path can't MITM a call. Media refs are content addresses, verified client-side.
Video EXIF/GPS is stripped on every iOS export path and on Android. Reports (
/flag) are signed, store no reporter identity, and expire (90-day TTL); blocking never leaves the device. Seedocs/SECURITY.md. - Apple app (iOS / iPadOS native, macOS native) — SwiftUI on the real Rust core via a
UniFFI XCFramework: circles + multi-circle feed, stories (multi-clip + captions),
DMs with recency sorting + iMessage-style conversation pinning (self-syncs across your
devices), group DMs with per-message sender name / timestamp / delivery checkmark,
in-app camera with filters, Apple Music on posts (and Shazam-named song credits on
videos, opt-out) that keep playing in the full-screen viewer, ducking only under a clip
with sound of its own, WebRTC 1:1 and group calls
(audio+video, screen share), multi-identity switcher with per-identity profiles,
a blind-APNs notification relay with on-device NSE decrypt, and an in-app/standalone
store-and-forward relay. macOS ships from a native AppKit/SwiftUI target (
HavenMac); Mac Catalyst was dropped 2026-06-23. - Apple Watch companion (
apple/HavenWatch) — a thin WCSession client for messages, photos, reactions, and quick replies (the phone keeps the iroh node + identity).
Also shipping, with known parity gaps: a native Android client (android/, Jetpack
Compose + the same Rust core via UniFFI/Kotlin — feed, DMs, stories, media bytes, WebRTC
calls, notifications, nearby, and the DM parity + own-device sync all ported; on Google
Play's internal track) and a Windows / Linux desktop client (desktop/, Tauri 2 — the
Rust backend links the core directly and the same binary runs headless as your circle's
relay; Linux + relay ship on GitHub Releases, Windows installers build but the install path
is still untested on real hardware; see docs/WINDOWS-PORT.md and
docs/ROADMAP.md for the exact per-platform gaps). The web client was
abandoned (a browser can't be an iroh peer); web/ is now just an invite-landing page. See
docs/ROADMAP.md and apple/README.md.
core/ Rust workspace — the portable, security-critical core
haven-p2p/ identity, hybrid-PQ crypto, links, social engine, transport seam
haven-net/ iroh QUIC networking node (listen/dial, sealed payloads)
haven-relay/ standalone store-and-forward relay daemon
haven-s3/ shared AWS SigV4 S3 client (BYO-storage mailbox) — used by the desktop client
haven-ffi/ UniFFI crate (`haven_ffi`) — Swift/Kotlin bindings
apple/ SwiftUI app (iOS/macOS) — consumes the core via an XCFramework
android/ Native Android app (Jetpack Compose) — same core via UniFFI/Kotlin
desktop/ Windows/Linux Tauri 2 app — Rust backend links the core directly; GUI + relay
relay/ Self-hostable relay packaging (launchd / systemd / Docker)
web/ Invite-landing / app-promo page (the web client was abandoned)
docs/ Architecture, decisions, threat model, link spec, roadmap
cd core
cargo testOne Rust core (haven-p2p) powers every client, so new platforms are mostly UI:
- iOS / iPadOS — SwiftUI + UniFFI (primary)
- macOS — native AppKit-backed SwiftUI (
HavenMactarget; Mac Catalyst dropped 2026-06-23 — seedocs/MACOS-NATIVE-PORT.md) - Android — native Jetpack Compose + the same core via UniFFI→Kotlin (live on Google Play)
- Windows / Linux — Tauri 2 (Rust backend links the core directly; WebView2/WebKitGTK
UI). GUI client and a headless circle-relay in one binary. Linux ships
.deb/.rpm/ AppImage and a sideloadablehaven.flatpak(Steam Deck) on GitHub Releases for Ubuntu / Debian / Raspberry Pi OS / Arch / SteamOS; PKGBUILDs live in-repo but Haven is not on the AUR or Flathub yet (seedocs/LINUX.md). Thehaven-relaydaemon cross-builds for x86_64/aarch64/armv7/armv6. The Windows GUI (x64 & Arm64) is live on the Microsoft Store and is no longer attached to GitHub Releases. Seedocs/LINUX.mdanddocs/WINDOWS-PORT.md - Apple Watch — glanceable companion (messages/photos/reactions/quick replies; not bulk video)
Haven is free — no ads, no tracking, no subscription, no in-app purchases — and it is built by one person. If it earns a place in your circle, you can help fund what comes next:
- Sponsor on GitHub — https://github.com/sponsors/blaineam
- Buy me a coffee on Ko-fi — https://ko-fi.com/wemiller
- All the ways to support — https://wemiller.com/support/
None of it is required, none of it unlocks anything, and none of it changes what the app does: your content stays on your devices, end-to-end encrypted, whether you chip in or not.
Free software under the GNU AGPL‑3.0‑or‑later (see LICENSE) —
read it, learn from it, fork it, build on it, even commercially. What you cannot do is
take it private: distributing a modified Haven, or running one (relay included) as a
network service, obliges you to publish your complete source under the same license.
The software comes without warranty; the copyright holder is not liable for your use of
it (AGPL §15–16). Copyright © Blaine Miller. The free official apps on the App Store,
Google Play, and Microsoft Store are published by the copyright holder, and an AGPL §7 app‑store distribution exception makes store distribution safe for compliant forks and future contributors alike. Contributions
are accepted under the DCO — see CONTRIBUTING.md, including the
policy on AI‑assisted changes.
docs/DECISIONS.md— the architectural decisions and whydocs/ARCHITECTURE.md— how the pieces fit togetherdocs/SECURITY.md— the security model in one place (crypto, what a relay can/can't do, deterrents)docs/THREAT-MODEL.md— what we defend against, and abuse resistancedocs/GROUP-KEYING.md— epoch sender-keys: revocation + bounded forward secrecy (PQ-preserving)docs/SEED-DROP-DESIGN.md— per-device keys + seedless linking: cryptographic device revocation (1.0.7)docs/TREEKEM-DESIGN.md— MLS-style TreeKEM on our own PQ primitives: PCS + forward secrecy (enabled in 1.0.7 for circles with a verified owner; older circles carry across only by invitation; internal audit, external review planned)docs/LINK-SYSTEM.md— the reach-me link / QR designdocs/MULTI-DEVICE.md— per-device transport identity + own-device sync convergence; many-device account design aheaddocs/SCHEDULED-MESSAGES.md— "send later" without a serverdocs/MEDIA-AND-MUSIC.md— in-app camera, Apple Music on posts, audio crossfadedocs/NOTIFICATIONS.md— blind APNs relay + on-device NSE decryptdocs/RELAY-AND-DEPLOY.md— relay roles, BYO storage, IP privacy, the deploy tooldocs/HAVEN-NET-RELAY.md— routing the relay/mailbox over Haven Net (no public host)docs/LORA-DESIGN.md— off-grid text over LoRa/Meshtastic radio: the compact wire profile the link would need (design spike, not built)docs/SATELLITE-DESIGN.md— Haven over carrier satellite data (T-Satellite): the ultra-constrained path APIs, low-data mode's policy table, and the carrier-allowlist problem (mode shipped in 1.6.0; carrier admission still a design question)docs/PREVIEW-TIER-DESIGN.md— a 512px AVIF preview tier (~6 KB) that crosses a satellite link first and upgrades to the full copy on return (design, not built)docs/BYO-STORAGE.md— bring-your-own S3 / cloud-drive storagedocs/OPERATING-COSTS.md— $0 operator cost modeldocs/EXPORT-COMPLIANCE.md— US export-compliance (automated)docs/MACOS-NATIVE-PORT.md— Mac Catalyst → native AppKit/SwiftUI portdocs/ANDROID-PARITY.md— the native Android client plan + statusdocs/WINDOWS-PORT.md— the Windows/Linux Tauri desktop client plan + statusdocs/LINUX.md— Linux GUI + headless relay: per-distro install (Ubuntu/Debian/Raspbian/Arch/SteamOS), packaging, paritydocs/WEB-PARITY.md— why the web client was abandoneddocs/ROADMAP.md— milestones and prerequisites
