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 10, 2026 · v1.6

🛡️ Our philosophy

RAVEN is built on a simple principle: your data belongs to you. We collect the minimum information necessary to operate the service, and we will never sell, share, or monetize your personal data. No hidden terms. No data harvesting. No third-party access beyond what's listed below.

📋 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. We collect only what's needed to deliver your messages. We never sell, share, or trade your data. Our business model is based on optional premium features, not advertising or 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 layer) 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.
Our servers run on Google Cloud Platform in Europe (Belgium). Data is encrypted at rest and in transit. We do not store data in countries with weak privacy laws.
Yes. We follow GDPR principles: data minimization, purpose limitation, right to erasure, and right to data portability. You can delete your account and export your data at any time.
We respond only to legally valid requests. Because messages are encrypted, we can only provide minimal metadata (account creation date, last login). We cannot provide message content.
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.
Only essential cookies for authentication on our website. We do not use 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 and email (if provided). The revision date at the top of this page always reflects the latest version.
👤
Account & Registration
A username and email address. You can also sign in with Apple or Google. Profile photo and bio are optional and can be changed or deleted at any time.
Your email is used for account recovery and critical security notifications only. We never send marketing emails. Your email is encrypted at rest on our servers.
No. Your email is never displayed to other users. Only your username and optional display name are visible.
Stretched on the server with Argon2id (time=3, memory=64 MiB, parallelism=4), with a unique salt per user. We never store plaintext passwords. Even our team cannot recover your original password. Shipped in v1.6: OPAQUE PAKE first iteration so the server never receives the password at all — see "Authentication" section below.
We receive only your name and email (with Apple's relay, if you choose to hide it). We do not access your Apple or Google contacts, photos, or other account data.
Everything: profile, messages, posts, media, friend list, group memberships, and all server-side metadata. Deletion is irreversible and completes within 30 days.
Yes. Go to Settings → Account → Download My Data. You'll receive a ZIP file containing all your messages, posts, media, and profile data.
Your messages in their chat history remain but show as "Deleted User". They cannot interact with your profile anymore.
Yes, profile photos are stored securely and encrypted at rest. They are deleted when you remove the photo or delete your account.
We store a device token for push notifications and a user-agent string for session management. We do not collect your device's unique hardware identifier, IDFA, or location.
Birth year is used only for age verification to comply with children's privacy laws (COPPA). It is not displayed publicly or shared with anyone.
💬
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. Our servers and every Bluetooth-mesh relay see only ciphertext we cannot decrypt — even under legal compulsion. 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 v1.7 / 2026 H2.
Our staff does not access user messages. Messages are encrypted at rest and access is restricted by strict internal policies. With full E2EE, even server-side access is impossible.
Messages are stored until you delete them. If you delete a message, it is removed from our servers within 24 hours.
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 and from our servers within 24 hours. We do not keep shadow copies.
Media is uploaded to our secure cloud storage (encrypted at rest). Files are linked to your account and deleted when you delete the message.
We retain minimal metadata (sender, recipient, timestamp) for delivery confirmation. IP addresses are not permanently logged. Metadata is purged after 90 days.
Yes. Go to Settings → Account → Download My Data to export all your messages and media as a ZIP file.
They cannot send you messages, see your online status, or view your profile. Existing messages remain in your history but can be deleted.
👥
Groups
Group names, member lists, and role assignments are stored on our servers. Group messages follow the same storage policy 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.
Public groups appear in search and allow join via link. Private groups are hidden from search and can restrict link joining.
Your user ID, the group ID, a reason category, and optional description. Message content is not automatically included in reports.
📇
Contacts
Only if you explicitly enable Contact Sync in Settings. By default, contacts are never uploaded.
Contact identifiers are hashed (SHA-256) before upload. We never receive or store raw contact data from your contact list.
SHA-256 with a server-side rotating salt. The salt changes periodically and old hashes are discarded.
Hashed contacts are retained only while Contact Sync is enabled. They are deleted within 24 hours of disabling sync.
Yes. Go to Settings → Privacy → Contact Sync → Off. This is off by default.
Yes. Previously uploaded hashes are deleted from our servers within 24 hours.
Never. We do not send SMS, emails, or notifications to your contacts without your explicit action.
Only if Contact Sync is enabled. Suggestions are based on matched hashes, not raw numbers. You can disable this separately.
📝
Posts & Feed
Posts are visible to your followers by default. You can change this per-post or set a global default in Settings → Privacy.
Yes. Deleted posts and their media are removed from our servers within 24 hours. Cached copies on other devices expire naturally.
View counts are real and based on unique authenticated views. We do not inflate or estimate view numbers.
Yes, for search and discovery purposes. This index is used only within RAVEN and is not shared externally.
User-reported content is reviewed by our moderation team. We do not use automated content scanning or AI moderation on posts.
Yes. Your data export includes all your posts, comments, and associated media files.
📡
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 the mesh path. 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.
A Bridge device relays messages between offline users and the server when it regains connectivity. It acts as a courier, not a reader.
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 — Sign in with Apple: if you choose this sign-in method, Apple sends us your name + email (or a relay alias if you opt for "Hide my email"). Optional.
  • Apple — Foundation Models (iOS 26): on-device only. Used for smart replies, conversation summaries, language detection. Nothing is sent off-device.
  • Apple — Translation (iOS 18+): on-device only after the language pack is downloaded. Used to translate Persian/Arabic/etc. into English for the on-device summariser.
  • Google — Sign in with Google: if you choose this sign-in method, Google sends us your name + email. Optional.
  • Google — Gemini (cloud): only invoked when you explicitly use the "Ask Gemini" feature on a public post. The specific post text is sent over TLS for processing. Your private DMs and group messages are never sent to Gemini. Disable in Settings → Privacy → AI Features if you don't want it available at all.
  • Google Cloud Run (Belgium, EU): our server hosting. Runs the FastAPI + WebSocket relay that buffers ciphertext between users. Cannot decrypt message content — every payload is end-to-end encrypted before it leaves your phone.
  • RevenueCat: handles RAVEN+ subscription receipts and entitlements via Apple's StoreKit. Receives an anonymised subscriber ID + which product you bought; never receives your messages, contacts, or content.
  • LiveKit (open source SFU, self-hosted): mixes audio for live audio rooms (Club). Audio is real-time only, never recorded, never stored. The SFU sees encrypted audio streams in transit.
  • 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.
Conversation summaries and smart replies run entirely on-device (Apple Foundation Models, iOS 26+). Nothing leaves your phone for those features. "Ask Gemini" on a public post is the only feature that sends content to a cloud AI provider — and only the specific post you tap on, only when you trigger it. Your private DMs, group messages, and Bluetooth-mesh traffic are never sent to any AI provider, and your messages are never used to train public models.
No. RAVEN has no advertising partners, no data brokers, no third-party tracking SDKs, and no IDFA / IDFV collection. Our business model is RAVEN+ subscriptions, not data.
🔐
Security & Data Retention
All data is encrypted at rest using AES-256. Database volumes use full-disk encryption. Backups are encrypted with separate keys.
Server access logs are retained for 30 days for security monitoring. IP addresses are not stored beyond the active session. Device metadata is retained while your account is active and deleted within 30 days of account deletion.
🔑
Authentication, key backup, and the v1.6 upgrade surface
OPAQUE is a zero-knowledge password authentication protocol where the server never receives the password — not even hashed. Shipped in v1.6 (first iteration): PBKDF2 + HKDF + AES-GCM-sealed credential envelope + ECDH-derived mutual session key. The server cannot recover your password and a database breach reveals zero usable credentials. Standards-compliant OPAQUE with the server-side OPRF round lands in v1.7.
Yes — shipped in v1.6. Sealed Sender encrypts the sender identity to the recipient's identity key (X25519 ephemeral + HKDF + AES-256-GCM), so the relay layer learns only "a message exists for X" — not "from Y". Modeled on Signal's design and verifiable in our open SealedSenderEnvelope.runDebugSelfTest().
Shipped in v1.6 (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. iCloud / cross-device sync of the same blob lands in stage 2. Wrong passphrase fails AEAD authentication — there is no "partial" restore, and the server cannot decrypt the backup even under legal compulsion.
Shipped in v1.6. 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 v1.6 (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→server, inbound envelopes go server→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 v1.6. 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 v1.6. 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 — 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.
Bookmarks and "save for offline" lists are local-only today — they live in your phone's encrypted UserDefaults and are not synced to any server. Cross-device bookmark sync is planned but not yet shipped; until then, the only place your bookmark list exists is on the device that made it.
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 today uses a single WebSocket, which is easy to filter. Domain fronting + pluggable transports (obfs4 / Snowflake-style) are committed for 2026 H2 so the online path keeps connecting under censorship without leaking that you are using Raven.
Stage 1 shipped in v1.6: 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 v1.7 (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 v1.6, 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