Encryption. Explained.

Security model in one minute

This applies to modern Brrro direct messages, group messages, message attachments, stories, profile posts, and call signaling. Brrro servers route encrypted data, store encrypted media, deliver notifications, and enforce access rules, but they are not designed to read the plaintext content of your encrypted messages, stories, posts, or attachments.

Brrro currently uses a one-active-device encryption model per account. Private keys are generated and stored only on the active device. They are never sent to Brrro servers, cloud backup services, support systems, logs, analytics, or any other external location.

Because Brrro does not keep private-key backups or key escrow, Brrro cannot restore old private keys if a device is lost, erased, reset, or replaced.

• Message content is encrypted before it leaves the sender's device.
• Attachments, voice notes, images, videos, stories, and profile-post media are encrypted before upload.
• Stories and profile posts use encrypted content payloads and per-recipient wrapped content keys.
• Direct calls use encrypted call signaling plus WebRTC media transport encryption.
• Private keys stay on the user's device only. Brrro does not upload, back up, sync, escrow, or log private keys.
• Brrro servers process routing and delivery metadata, but are not designed to read encrypted content.

Private keys never leave your device

For Brrro, end-to-end encryption means the secret/private key material needed to decrypt your private content is created locally and remains on the user's device.

Brrro servers receive only the public key material and encrypted envelopes needed to route and deliver encrypted content. The server never receives the private keys needed to decrypt that content.

Brrro does not currently support encrypted backups, cloud key backup, support-assisted key recovery, key escrow, or a server-side private-key copy. If the local private keys are lost, Brrro cannot retrieve them for you.

A future multi-device option may allow a user to pair another device by scanning a QR code and transferring necessary key material directly between the user's devices. That feature is not supported today, and it would not change the rule that Brrro servers do not receive private keys.

• No private keys are uploaded to Brrro servers.
• No private keys are sent to backups or third-party storage.
• No private keys are stored for support, recovery, analytics, or logging.
• No employee, server process, or admin tool has a private-key copy to recover.
• Only public device material and encrypted payloads are stored server-side for delivery and session setup.

1. Device identity and key lifecycle

Each Brrro device creates its own cryptographic identity material on-device.

The backend stores public device material needed for delivery and session setup. Private key material stays on the user's device and is not uploaded, synced, backed up, escrowed, or logged by Brrro.

If a contact's active device identity changes, Brrro can show a safety/device-change warning so users are not silently moved onto an unexpected identity.

• Curve25519 identity keys for secure session establishment.
• Ed25519 identity keys for signing and verification.
• One-time prekeys and fallback keys for new secure sessions.
• Device-published content-wrap keys for stories and profile posts.
• Keychain-backed storage for sensitive device-local key material.

2. Direct messages

Direct messages use Brrro E2EE v2.

A direct message is encrypted into a device-targeted envelope before it is sent to the backend. The backend queues and routes that encrypted envelope to the recipient's active device. The recipient decrypts it locally, applies it to the chat, and then acknowledges the encrypted envelope.

Brrro servers can see delivery metadata required to route the message, such as sender, recipient, device identifiers, timestamps, and envelope type. They are not designed to read the plaintext body of the message.

Delivery and read receipts are also sent through encrypted messaging paths.

3. Group chats

Group chats use encrypted group-message payloads with sender-key style group state.

The server needs to know group membership and delivery metadata to route group messages. It is not designed to read the plaintext content of encrypted group messages.

• Group membership and routing are coordinated by the backend.
• Group message content is encrypted before upload.
• Group sender keys are distributed to members using pairwise E2EE transport.
• Group messages are delivered as encrypted envelopes to the intended recipient devices.
• Read/delivered state can be processed without exposing plaintext message bodies to the server.

4. Attachments, images, videos, files, stickers, and voice notes

Media and attachments are encrypted before upload.

For attachments and media, Brrro uses client-side symmetric encryption, including AES-GCM with a per-item encryption key. The encrypted blob is uploaded to Brrro media storage. The decryption key is then shared through the encrypted message, story, or post payload path.

This means the media server stores encrypted bytes, not the original image, video, voice note, or file.

Brrro also enforces media access rules. For example, story media, profile-post media, and message attachments are scoped to the author, intended recipients, or eligible conversation participants.

5. Stories

Stories are encrypted for their intended audience.

Brrro can process story audience information, expiry, views, likes, and routing metadata. It is not designed to read the plaintext story content or the plaintext story media.

• The story content payload is encrypted on-device.
• The story media is encrypted before upload.
• A content key is wrapped separately for each intended recipient device.
• Recipient devices unwrap the content key locally and decrypt the story.
• The backend stores encrypted story payloads, encrypted media references, recipient rows, and delivery/view metadata.

6. Profile posts and feed media

Profile posts use the same modern content-encryption model as stories.

This lets Brrro show social features like feeds, profiles, likes, replies, visibility rules, and media access control while keeping post content and post media encrypted from the server's point of view.

Some social metadata is necessarily visible to Brrro for the feature to work, including author ID, audience eligibility, post IDs, timestamps, view/like/reply events, and delivery state.

• The post content payload is encrypted on-device.
• The media is encrypted before upload.
• The content key is wrapped for eligible recipient devices.
• The backend stores the encrypted content envelope, encrypted media reference, audience metadata, and social interaction metadata.

7. Calls

Brrro calls use two security layers.

First, call signaling is sent through Brrro's encrypted v2 envelope system. This includes call setup messages such as offers, answers, hangups, and call-control state.

Second, call media uses WebRTC/LiveKit transport security. WebRTC media is protected in transit using standard encrypted media transport such as DTLS-SRTP.

In short: Brrro encrypts call setup signaling through its E2EE message infrastructure, while live audio/video transport uses the encryption provided by the WebRTC stack.

8. Notifications

Brrro uses push notifications to wake the app and notify users about new activity.

For encrypted message flows, the notification system is designed so the app or notification extension can fetch/decrypt encrypted content on-device where supported. The backend still handles notification routing metadata and may send generic notification information needed by Apple Push Notification service.

Some notification metadata is unavoidable, such as recipient device, push token, notification type, and timing. Brrro's goal is to avoid exposing plaintext encrypted-message content to server-side notification infrastructure.

9. What Brrro can see

Brrro infrastructure may process metadata required for the service to work. This metadata is needed for delivery, reliability, notifications, safety, and product functionality.

• Account and device identifiers.
• Sender and recipient identifiers.
• Conversation, group, story, or post identifiers.
• Delivery timestamps and envelope types.
• Media blob identifiers and access-control state.
• Social metadata such as likes, views, follows, visibility rules, and counters.
• Operational telemetry, errors, and abuse-prevention signals.

10. What Brrro is not designed to see

In modern encrypted flows, Brrro servers are not designed to read:

• Plaintext direct-message bodies.
• Plaintext group-message bodies.
• Plaintext message attachments.
• Plaintext voice notes.
• Plaintext story media.
• Plaintext profile-post media.
• Plaintext encrypted story/post content payloads.
• Plaintext encrypted call-signaling payloads.

11. Device changes, no key backup, and reliability

Brrro supports reliability flows for encrypted delivery, but these are not private-key backup or private-key recovery.

If a device is lost, erased, reset, or the app is removed, Brrro cannot restore the old private keys from the server because the server never had them.

When an account moves to a new active device, Brrro establishes fresh device keys for future encrypted communication. Some old encrypted content may not be recoverable on the new device if the original private keys are gone.

Multi-device use is not currently supported. If Brrro adds it later, the intended model is explicit device-to-device pairing, for example scanning a QR code, so key material can be transferred directly between the user's devices without sending private keys to Brrro servers.

• Device bootstrap and fresh key generation.
• One-time key replenishment.
• Pending encrypted-envelope delivery.
• Decryption-error repair flows that do not expose private keys to the server.
• Audience repair for stories and profile posts when recipient device material changes.
• Safety/device-change handling when a contact's identity changes.

12. Limits of end-to-end encryption

End-to-end encryption protects content in transit and at rest on Brrro infrastructure, but it does not protect against every possible risk.

Brrro E2EE does not protect against:

• A compromised or unlocked device.
• Another camera pointed at the screen.
• Malware or OS-level compromise.
• A recipient manually sharing content outside Brrro.
• Metadata analysis based on timing, participants, or social graph activity.

13. Technical summary

Current Brrro secure communication uses:

Brrro is designed so private content is encrypted before it reaches Brrro servers, while still supporting modern social features such as stories, posts, feeds, media, group chats, calls, and notifications.

• Private keys generated and kept on device only.
• Curve25519 device identity/session material.
• Ed25519 signatures for device/content-wrap verification.
• Olm/vodozemac-style pairwise secure sessions for direct encrypted transport.
• One-time prekeys and fallback keys for session setup.
• Sender-key style symmetric group-message encryption.
• AES-GCM for attachment/media/content-key encryption.
• X25519 + HKDF-SHA256 + AES-GCM for content-key wrapping on stories and profile posts.
• WebRTC DTLS-SRTP transport encryption for call media.
• Keychain-backed local storage for sensitive device key material.
• No private-key upload, cloud backup, support recovery, key escrow, or server-side private-key copy.