Why Raven How It Works Features Privacy FAQ Try the Beta

Privacy Policy

Your data, your rules. We believe in full transparency, including about what we have not shipped yet.

Last updated: May 27, 2026 · v2.0

Our philosophy

RAVEN is built on a simple principle: your data belongs to you. RAVEN is fully serverless with no account. There is no central server holding your messages, credentials, or contact graph, so there is effectively nothing for us to collect. We will never sell, share, or monetize your personal data. No accounts. No data harvesting.

Honest disclosures: what's true today, what's not yet

A privacy policy that overstates is worse than none, so:

If we miss a date, we will say so on this page. Trust earned by inspection is the only kind worth having.

General & Transparency
Minimal data. Maximum transparency. RAVEN is fully serverless with no account, so there is effectively nothing for us to collect. Your messages travel end-to-end encrypted over Bluetooth mesh and a relay-only internet bridge. We never sell, share, or trade your data. RAVEN is free forever, with no advertising, no subscriptions, no data harvesting.
RAVEN is an independent project built by a small team focused on privacy-first communication. We are not owned by or affiliated with any advertising or data brokerage company.
Not yet, and we will not pretend otherwise. The cryptographic core (X3DH / Double Ratchet implementation, MeshEnvelope parser, BLE transport, libp2p bridge) is committed for open-source release under an audit-friendly license alongside the third-party audit in 2026 H2. Application code follows in stages. Until then, security researchers can request review access to the security-critical sources by emailing privacy@raven-messager.com.
Not yet. A third-party engagement with Cure53 / Trail of Bits / NCC Group-tier engagement is committed for 2026 H2 against the cryptographic core, the mesh envelope, and the BLE protocol layer. The full report will be published in the open. "Designed to be reviewed" is not the same as "audited". We know.
RAVEN is fully serverless. There is no central server storing your messages, credentials, or contacts. A libp2p relay/bootstrap node helps relay encrypted bridge traffic between peers, but it only ever sees opaque ciphertext, never your plaintext, accounts, or identity. Your data lives only on your own devices.
Yes. We follow GDPR principles by design: because RAVEN is serverless with no account, there is no central store of your personal data to begin with. Your data lives only on your devices. You delete it by deleting it locally or removing the app.
We respond only to legally valid requests. Because RAVEN is serverless with no account, we hold no messages, no accounts, and no contact graph. There is no message content, no account creation date, and no login history for us to produce. The relay node sees only opaque ciphertext.
No. We do not use tracking pixels, cross-app identifiers, or third-party analytics SDKs. We have no advertising partners and no interest in tracking your behavior.
None for authentication. There is no account or login. Our website does not set tracking cookies, analytics cookies, or any third-party cookie services.
Email privacy@raven-messager.com. We respond to all privacy inquiries within 48 hours.
Yes. Material changes will be announced via in-app notification. The revision date at the top of this page always reflects the latest version.
Identity & Setup
Nothing personal. There is no account, no sign-up, no email, no phone number, and no password. On first launch RAVEN generates an Ed25519 + X25519 keypair on your device and derives your userId from it. The only setup step is choosing a local display name.
No. RAVEN has no password, no login, and no server to store one. Your identity is a hardware-bound keypair in the Secure Enclave / Keychain. You can lock the app locally with Face ID, and an optional passphrase protects encrypted key backup, but there is no account credential anywhere.
There is no account to delete and no server-side data to erase. Everything lives on your device: deleting a conversation, your keys, or the app itself removes it. Your peers keep only the encrypted messages you already sent them.
No. There is no server session and no account, so we store no device token, no user-agent, and no session data. We do not collect your device's hardware identifier, IDFA, or location.
Messages & Chats
Yes, end-to-end. Every 1:1 conversation runs the Signal protocol (X3DH for asynchronous key agreement + Double Ratchet for per-message key rotation). Forward secrecy means yesterday's keys can't decrypt today's messages and vice versa. The relay node and every Bluetooth-mesh hop and the libp2p relay see only ciphertext nobody but the recipient can decrypt. There is no server holding plaintext. Group chats today use per-group AES-256-GCM symmetric keys (rotated when a member is removed); migration to MLS (RFC 9420) is committed for a later release.
No. RAVEN is serverless and end-to-end encrypted, so your messages never reach us in any form, encrypted or otherwise. There is no server-side store for anyone, including us, to access.
No. RAVEN has no message server. Messages live only on the sending and receiving devices. The relay node may briefly hold an encrypted envelope in transit until it is delivered, then drops it. It never stores a readable copy.
Yes. Messages are cached locally in an encrypted SQLite database for offline access. This data stays on your device only.
No. We do not scan, read, or analyze message content. Spam detection relies on metadata patterns (rate, volume), not content.
Yes. When you delete a message it is removed from your device immediately. Because RAVEN is serverless there is no server-side copy to delete, and the encrypted envelopes a relay briefly holds to reach offline peers age out on their own. We keep no shadow copies.
Media (photos, voice notes, files) travels end-to-end encrypted over the same serverless transport as text: Bluetooth mesh plus the libp2p bridge. It is never uploaded to a central server and lives only on the devices in the conversation.
No. There is no central server to keep delivery logs. Sealed-sender means even the relay node sees a hashed identity token rather than your raw userId, and it retains nothing once an encrypted envelope is delivered.
They can no longer reach you over mesh or the bridge, and you can remove them as a contact. Existing messages remain in your local history but can be deleted.
Groups
Group names, member lists, and role assignments live only on members' devices. There is no server-side group record. Group messages follow the same serverless, end-to-end-encrypted path as direct messages.
Admins can: rename the group, change the photo, add/remove members, promote/demote roles, and reset invite links. Admins cannot read private messages.
Members can export their own messages via Settings → Download My Data. They cannot bulk-download other members' messages.
You stop receiving messages. Your past messages remain visible to group members but you can delete them before leaving.
Invite links are generated with a unique random token. They do not expire by default but can be reset by admins, which invalidates the old link.
Yes. Admins can reset the invite link at any time, which immediately invalidates the previous link.
Contacts
Never. RAVEN has no contact sync and no server to upload to. You add contacts in person by scanning a QR code (out-of-band key pinning); your address book never leaves your device.
Never. We do not send SMS, emails, or notifications to your contacts without your explicit action.
Mesh / Offline / Bridge
Encrypted message payloads (opaque to relays), anonymised sender/recipient hashes (not raw user IDs), timestamps, and TTL counters. No personal profile data, no contact graph, no geographic data is shared in the mesh frame itself. However, radio-layer traffic analysis can still reveal which devices are talking to which on the airwaves; we mitigate today with anonymised hashes + dedup + randomised re-broadcast jitter, and ship constant-rate cover traffic in 2026 H2.
Yes. The same end-to-end protocol that protects internet messages (Signal X3DH + Double Ratchet) protects both the mesh path and the libp2p internet bridge. Relay devices forward bytes they cannot read, modify, or impersonate. Every envelope is independently signed (Ed25519) and sealed (AES-256-GCM) by the original sender.
The bridge carries encrypted envelopes over the internet between peers using libp2p (Kademlia DHT, Circuit Relay v2, hole-punching, Noise streams). The relay node it traverses is a blind courier: it forwards opaque ciphertext and never reads it.
No. Messages are encrypted end-to-end for mesh transfer. Relay devices only see opaque encrypted payloads.
Messages have a TTL (Time to Live) of 24 hours and a maximum of 5 hops. After either limit, the message is discarded.
Each message has a unique nonce. Devices maintain a seen-nonce cache to reject duplicates. Expired TTL messages are also rejected.
No. When your device relays messages for others, your identity is never attached to the payload. Relay devices are anonymous couriers: they cannot read the message, and neither the sender nor the recipient knows which device relayed it.
Third-Party Services
The complete list of code we did not write that ships with the app or runs server-side:
  • Apple · APNs (Apple Push Notification service): receives a wake-up ping with your device token to alert you of a new message. It does not receive message content, only "you have something new". Required for push to work on iOS.
  • Apple · Foundation Models (iOS 26): on-device only. Used for smart replies, conversation summaries, language detection. Nothing is sent off-device.
  • Apple · on-device language model: on-device only. Used for smart replies, conversation summaries, and multi-language pivot. Nothing leaves your device.
  • libp2p relay / bootstrap node: a blind relay that forwards encrypted bridge envelopes between peers (Circuit Relay v2 over the libp2p DHT). It never holds accounts, identities, or plaintext. Every payload is end-to-end encrypted before it leaves your device.
  • SQLCipher (open source library): encrypts the on-device SQLite database with AES-256. Runs entirely on your device.
Not used: no Crashlytics, no Sentry, no Mixpanel, no Datadog, no Firebase Analytics, no Facebook SDK, no advertising SDK, no fingerprinting library. Zero analytics SDKs ship in the app binary today.
All AI features run entirely on-device (Apple's on-device foundation model). Smart replies, conversation summaries, and multi-language pivot never leave your phone. RAVEN sends nothing to any cloud AI provider, and your messages are never used to train any model.
No. RAVEN has no advertising partners, no data brokers, no third-party tracking SDKs, and no IDFA / IDFV collection. RAVEN is free forever. There is no subscription and no data-driven business model.
Security & Data Retention
We have no servers that store your data. RAVEN is serverless; the relay node forwards opaque ciphertext and keeps no database. On your device, the local message store is encrypted with AES-256 via SQLCipher and keys are hardware-bound in the Secure Enclave.
There is no application server keeping access logs, and no account to attach metadata to. The relay node processes encrypted envelopes in transit and retains no per-user logs or device metadata.
Authentication, key backup, and the v2.0 upgrade surface
Yes, shipped in v2.0. Sealed Sender encrypts the sender identity to the recipient's identity key (X25519 ephemeral + HKDF + AES-256-GCM), so the relay node learns only "a message exists for X", not "from Y". Modeled on Signal's design and verifiable in our open SealedSenderEnvelope.runDebugSelfTest().
Shipped in v2.0 (opt-in). You set a recovery passphrase the server never sees; we derive a 256-bit key (PBKDF2-SHA256, 600 000 iterations), encrypt your identity + ratchet state with AES-256-GCM, and store the opaque blob locally. Cross-device sync of the same blob lands in a later release. Wrong passphrase fails AEAD authentication. There is no "partial" restore, and nobody (including us) can decrypt the backup, because keys are hardware-bound and never leave your device in usable form.
Shipped in v2.0. Every 180 days your identity keypair rotates automatically. The transition is recorded as a cross-signed certificate: BOTH the old key signs the new one, AND the new key signs the old one. This means a peer who sees only your new key can still prove provenance back to the old one (and vice versa). The certificate chain is locally verifiable forward and backward; the key continuity is preserved without you having to re-add anyone.
Shipped in v2.0 (opt-in). When you turn on Helper Mode, your online phone can act as a cipher-text relay for nearby offline neighbours over BLE: their outbound envelopes go phone→bridge, inbound envelopes go bridge→phone→neighbour. The gateway is cryptographically blind: it sees only a recipient hint, an opaque ciphertext blob, and a per-relay nonce. It cannot read the plaintext, cannot identify the original sender (Sealed Sender hides that too), and cannot see group membership. Token-bucket rate limiting per neighbour (100 KB burst, 1 KB/s steady) prevents abuse; memory-hygiene primitives zero-fill in-flight envelopes after forwarding; the service deactivates automatically when the phone is hot, low on battery, or fully backgrounded.
Shipped in v2.0. Sensitive payloads are wrapped in TWO authenticated-encryption layers from different cipher families: inner ChaCha20-Poly1305 (stream-cipher math) wrapped in outer AES-256-GCM (block-cipher math), with a key-committing HMAC-SHA256 tag binding both keys + the nonce + the outer ciphertext. Both ciphers must fall before the plaintext leaks; the commitment HMAC defeats the Salamander class of multi-key collision attacks. Inner and outer keys are independently derived (HKDF with different info strings), never split from a single block.
Shipped in v2.0. Sensitive byte buffers (chain keys, ratchet roots, in-flight plaintext, in-flight gateway envelopes) live in a SecretKey primitive: page-locked with mlock so the OS can't write them to swap, and triple-zeroised on deinit (0x00 / 0xFF / 0x00, where the alternation pattern defeats compilers that elide the second pure-zero pass as redundant). The gateway service additionally zero-fills its priority queue's backing buffers when Helper Mode deactivates, so a later RAM dump can't recover envelopes that were merely held.
App-layer crypto neutralises pairing-level attacks: every envelope is signed (Ed25519) and encrypted (AES-256-GCM), so a downgrade or impersonation at the BLE pairing layer cannot inject a forged message or read a real one. We do not rely on BLE pairing for confidentiality. Protocol-level mitigations (encrypted pairing where the host stack supports it, MITM-resistant GATT verification) are explicit audit scope for 2026 H2.
The Bluetooth-mesh path is unaffected by network filtering: local device-to-device messaging works regardless. The online path uses a libp2p bridge (Kademlia DHT, Circuit Relay v2, hole-punching, Noise streams), which is harder to block than a single endpoint. Additional censorship-resistant transports (domain fronting / pluggable transports) are committed for a later release.
Stage 1 shipped in v2.0: every release ships with a published manifest of source SHA-256 + Mach-O SHA-256 + bundle SHA-256. Anyone can re-run our open verify-binary.sh and check the hashes match. Stage 2, bit-for-bit reproducible IPAs, targets v2.1 (we need to pin Xcode + strip codesign timestamp + canonicalise embedded build paths). Until stage 2 you can verify "the source is what we say it is", not yet "the App Store binary was compiled from that exact source".
By default, keys are hardware-bound and don't survive device loss, which means we cannot recover them either. With encrypted key backup & recovery (shipped in v2.0, opt-in), you can restore your identity + sessions on a new device using a passphrase the server never sees. Wrong passphrase fails AEAD authentication, so a leaked backup blob is useless without your secret.
No topics match your search. Try different keywords.

Questions about your privacy? Email us at privacy@raven-messager.com