Frequently Asked Questions

RAVEN is a private, fully serverless messenger with offline mesh networking. There is no account and no central server holding your messages. RAVEN can send messages over the internet bridge or, when there's no internet, via Bluetooth, device to device.

Nothing but the app. There's no account, no sign-up, no email or phone number. On first launch RAVEN generates an Ed25519 + X25519 keypair on your device and derives your ID from it. The only setup step is choosing a local display name.

Scan a contact's QR code in person to pin their key out-of-band, or use the 1-RTT first-contact path. Adding and removing contacts is instant. There is no server-side contact graph.

Your identity keys live on one device. RAVEN runs on iPhone, iPad, and Mac, with Apple Watch as a companion. There is no login to move between devices. Your keys are hardware-bound to the device that generated them.

Because keys are hardware-bound and never leave the device, a fresh install starts a new identity by default. Optional recovery paths, a passphrase-sealed key backup and 3-of-5 social recovery, let you restore your identity if you set them up in advance.

Yes. Every 1:1 conversation uses X3DH for asynchronous key agreement and the Double Ratchet for per-message key rotation, wrapped inside the ATSAM protocol stack. The result is end-to-end encryption that is forward-secret and post-compromise secure. RAVEN has no message server. The only relay is a libp2p bridge node that forwards encrypted envelopes it can never decrypt, even under legal compulsion.

Forward secrecy means a stolen key today cannot decrypt the messages you sent yesterday. Every message has its own key, derived from the previous one and then erased. Raven now ships forward secrecy via the Double Ratchet on every 1:1 conversation, on both internet and Bluetooth mesh paths.

Open the chat → tap their name → Verify Identity. Raven derives a 60-digit Safety Number from both identity keys. Compare it once: in person, on a video call, or by scanning the QR. If the numbers match, no man-in-the-middle is possible even if the carrier, the ISP, and the relay node cooperated against you.

Only on your device. RAVEN has no message server. Messages are delivered peer-to-peer over the BLE mesh and the libp2p internet bridge, and stored in an encrypted local database (SQLCipher / AES-256). The bridge relay forwards encrypted envelopes but never stores or decrypts them.

Voice messages: up to 5 minutes. Files: up to 25 MB. Location: shared as a one-time pin (not live tracking). Image compression is automatic.

Single check = sent. Double check = delivered to device. Blue checks = read by recipient. You can disable read receipts in Settings → Privacy.

Online status shows when you have the app open. You can hide your status in Settings → Privacy → Show Online Status.

This can happen during brief network drops. Pull down to refresh the chat, or the message status will auto-update within a few seconds.

Delivered = the recipient's device received it. Seen = the recipient opened the chat and the message was on screen. Both require an active connection.

Swipe left on the conversation in the Messages list and tap the bell icon. You can choose: 1 hour, 8 hours, 24 hours, 1 week, or permanently.

Open the conversation and remove or block the contact. Because contacts are pinned on your device and there is no server contact graph, blocking simply stops your device from accepting their envelopes.

When there's no internet, RAVEN uses Bluetooth to find nearby phones running RAVEN. Your message hops from phone to phone until it reaches the recipient, or until a phone with internet relays it onward over the encrypted libp2p bridge. All automatic, all encrypted.

Mesh works best within Bluetooth range (~10 to 30m). It's designed for nearby communication: concerts, campuses, or subway cars. It is NOT a replacement for internet. Think of it as a safety net when connectivity fails.

Mesh mode uses Bluetooth Low Energy (BLE) to create a local device-to-device network. Messages hop from phone to phone, up to 5 hops, to reach the recipient without internet.

Bluetooth range is typically 10 to 30 meters. With multi-hop relay (up to 5 hops), the effective range can extend to ~150 meters depending on environment and obstacles.

Up to 5 hops. Each relay device decrements the hop counter and forwards the message. After 5 hops, the message is no longer relayed to prevent infinite propagation.

Minimal impact. RAVEN uses Bluetooth Low Energy (BLE), designed for efficiency. Background scanning is managed by iOS to minimize battery usage.

Bridge is when a mesh device regains internet and relays stored encrypted envelopes onward over the libp2p internet bridge (Kademlia DHT, Circuit Relay v2, hole-punching, Noise streams). It bridges the offline mesh with the online relay path. Fully automatic.

The first copy is accepted. The duplicate is silently discarded using the nonce-based deduplication system. You only see one message.

A Bridge device may relay the encrypted envelope onward over the libp2p bridge so it can reach the recipient. The relay never stores or decrypts it. If you already received it via mesh, the duplicate is deduplicated on your device.

Yes. All mesh payloads are encrypted before transmission. Relay devices only see opaque encrypted data and cannot read the content.

iOS restricts background Bluetooth activity. RAVEN works best when the app is in the foreground. Background mesh is limited to brief windows when iOS allows it.

Multi-hop relay depends on all intermediate devices being in range and having RAVEN open. iOS background restrictions can interrupt the relay chain.

Bridge reliability depends on Bluetooth signal quality and iOS background execution limits. We continuously improve this with adaptive retry logic.

That phone uses the internet bridge path. It won't participate in mesh networking. Other nearby devices with Bluetooth can still mesh with each other.

Not yet. Mesh currently supports 1:1 messages only. Group mesh support requires additional routing logic and is planned for a future update.

Tap the group icon in Messages. Add members and set a name. Current limit is 100 members per group.

Admins can: rename the group, change the photo, add/remove members, promote/demote other admins, generate/reset invite links, and set group visibility.

Admins can generate a shareable link from Group Settings → Invite. Anyone with the link can join. Admins can reset the link at any time to invalidate old ones.

Open Group Settings → scroll to the bottom → Leave Group. Your past messages remain but you stop receiving new ones.

Admins can swipe left on a member in Group Settings to see actions: Set Nickname, Promote to Admin, Demote, or Remove from Group.

Group Settings → Customize → Chat Wallpaper. Choose a preset or pick from your gallery. Wallpaper is saved locally per-user, not synced across members.

Make sure you tap 'Done' after selecting. If the issue persists, try restarting the app. Gallery images are compressed and saved locally.

This is a known issue with large gallery images. We compress images to max 1080px, but very large files may cause a brief layout recalculation.

Tap the bell icon in Group Settings. Choose a mute duration or 'Always'. You can also enable 'Mentions Only' to get notified only when you're mentioned.

Identity: Ed25519 signatures on every message. Content: AES-256-GCM (with ChaCha20-Poly1305 as a backup cipher). Key agreement: X3DH over X25519 ECDH, then the Double Ratchet for per-message rotation, all wrapped inside the ATSAM protocol stack. All keys derived through HKDF-SHA256 and stored in iOS Keychain, hardware-bound to the Secure Enclave. RAVEN has no password and no login. Your identity is the on-device keypair, so there is nothing for a server to authenticate or store.

Yes, both. Forward secrecy means a stolen key today cannot decrypt the messages you sent yesterday; post-compromise security means a single new handshake heals any conversation that was briefly exposed. Both are provided by the Double Ratchet, which now runs on every 1:1 conversation in Raven, on internet AND mesh.

Open the chat → tap their name → Verify Identity. Raven derives a 60-digit Safety Number from both identity keys (SHA-512 ×5,200). Compare it once: in person, on a video call, or by scanning the QR. If the numbers match, no machine-in-the-middle is possible, even if the carrier, the ISP, and the relay all colluded.

Not yet, and we say that openly. We are commissioning a third-party audit (Cure53 / Trail of Bits / NCC Group-tier engagement) against the cryptographic core for 2026 H2 with the full report published in the open. "Designed to be reviewed" is not the same as "audited." We know, and we will not pretend otherwise until the report is on this site.

Not yet. We plan to open-source the cryptographic core (X3DH / Double Ratchet implementation, mesh envelope, BLE protocol layer) under an audit-friendly license alongside the third-party audit in 2026 H2. Application code follows in stages. In the meantime, security researchers can request review access to the security-critical sources by emailing info@raven-messager.com. We'd rather you check than take our word for it.

Reproducible builds are committed for v2.1. Anyone will be able to rebuild the App Store binary from public sources and verify it byte-for-byte. Until then, the SHA-256 of every release binary is published so you can at least confirm you have the artefact we shipped.

Yes. RAVEN's sealed-sender design signs over hashed identity tokens, so raw user IDs never ride the wire. The relay never sees who sent a message. There is no IP storage, no contact graph, and no analytics anywhere in the relay path.

Today: per-group symmetric AES-256 keys with key rotation when a member is removed (correct, but not as scalable or as provably secure as MLS). Migration to MLS (RFC 9420), Messaging Layer Security, the IETF standard for group ratcheting, is committed for 2026 H2 in v2.1. MLS gives us per-group continuous group key agreement that scales to thousands of members with the same forward-secrecy guarantees as 1:1.

A real concern, and we will not hand-wave it. The encrypted envelope hides content, but radio-layer traffic analysis can reveal who-talks-to-whom. Today we mitigate with: anonymised sender/recipient hashes (no usernames in the envelope), per-relay SHA-256 deduplication, and randomised re-broadcast jitter. Coming 2026 H2: constant-rate cover traffic + decoy envelopes at the radio layer to flatten observable patterns. The third-party audit will explicitly cover this surface.

Keys are hardware-bound to the Secure Enclave and are not in iCloud backups. By design, this means we cannot recover them either. Two recovery paths are available: (1) an optional passphrase-sealed key backup, encrypted with a user-chosen recovery passphrase that no one else ever sees; and (2) 3-of-5 social key recovery: split your recovery key into five Shamir shares wrapped per-contact with ECIES, restored by collecting three back from your trusted contacts. Pick the trade-off you want: maximum privacy (no backup), passphrase backup, social recovery, or all three.

Two answers: (1) the Bluetooth mesh path is not affected by network filtering at all, so local communication keeps working even when the internet is blocked; (2) the online path is a peer-to-peer libp2p bridge (Kademlia DHT, Circuit Relay v2, NAT hole-punching over Noise streams) rather than a single fixed endpoint, which is harder to block than one server address. Pluggable-transport obfuscation is on the roadmap.

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 part of the 2026 H2 audit scope.

Nothing on a server, because there is no account server. Your local display name and keys live on your device; messages are end-to-end encrypted and stored only on your device. We collect no email, no phone number, no contact graph, and no analytics/tracking data. Push notifications carry no message content, only a wake-up.

No. We do not share, sell, or trade your data with anyone. We have no advertising partners, no analytics SDKs, and no data broker relationships. Apple delivers our push notifications and that is the extent of third-party involvement.

There is no account and no server store of your data. Encrypted messages live only on your device until you delete them, and would be unreadable to anyone else regardless. Relay nodes forward encrypted envelopes without storing them. To erase everything, delete the app. Your keys and local database go with it.

Apple Watch ships as a companion: read messages, react, and reply by dictation/scribble through the paired iPhone. (Watch can't be a real BLE mesh peer: that's a watchOS API limit, not a roadmap item.) RAVEN runs on iPhone, iPad, and Mac, all speaking the same MeshEnvelope wire format, so cross-platform interop is automatic.