What is Buzzio?
Buzzio is a privacy-first messaging platform. Its architectural promise is not “we encrypt some traffic,” but:
On sealed surfaces, Buzzio aims to be a blind relay, not a permanent cloud archive of private conversations.
Readable private history lives in an encrypted local database on user devices. Shared-history products (communities, broadcast, open-history groups, Stories, Whisper Questions) store more by design, and say so.
Operator: Buzzio Team · Site: https://buzzio.dev · Age: 13+ (optional Bitcoin wallet 18+)
Product in one paragraph
Users create a Buzzio ID (random 12-digit address) and a 12-word recovery phrase on-device. Private messaging keys never leave the device. Private 1-to-1 messages are end-to-end encrypted (X3DH + Double Ratchet), optionally wrapped in sealed-sender envelopes, relayed briefly, then deleted after delivery. The same app also offers Discord-style communities, broadcast channels, Stories, encrypted calls, and anonymous Whisper QR sessions — with an explicit privacy matrix so “encrypted” is never confused with “operator-blind.”
Two honest product modes
| Mode | Surfaces | Server role | History |
|---|---|---|---|
| Sealed | 1-to-1, Whisper private chat, E2E groups, private calls | Relay ciphertext; minimal durable graph after delivery/expiry | Local (SQLCipher) or session-scoped |
| Shared | Open-history groups, Communities, Broadcast, Stories, Whisper Questions | Operate the product with server-held or server-managed keys | Durable for retention windows |
Buzzio does not sell messages, metadata, Buzzio IDs, community posts, Whisper content, backups, or wallet activity in either mode.
Why this exists
Typical messengers force a trade-off:
- Signal-class secrecy with a narrow social surface, or
- Telegram/Discord-class features with cloud-first history and weaker default privacy framing
Buzzio ships both, but labels them honestly. Privacy leadership here means:
- Sealed surfaces approach Signal-class content + envelope goals on a Firebase stack.
- Shared surfaces remain usable platforms without pretending they are sealed.
- Identity is not tied to a personal phone number.
See Why Buzzio ranks in the privacy market for the full argument.
Identity model
| Element | Behavior |
|---|---|
| Buzzio ID | Random public address (not derived from the phrase) |
| 12-word mnemonic | BIP39-style phrase; derives messaging keys on-device |
| Private keys | Never uploaded; never recoverable by Buzzio staff |
| @username | Optional mapping to the same account |
| Firebase Auth | Synthetic account binding for infrastructure; not a personal email the user provides |
New-device login requires Buzzio ID + phrase. Losing all devices and the phrase (with no unlockable encrypted backup) means private keys cannot be rebuilt.
Platform stack (summary)
- Client: Flutter app (
ghost_protocolpackage name historically) - Auth / ops: Firebase Auth, App Check, FCM, Analytics
- Relay & signals: Firebase Realtime Database (pending sealed inbox, Whisper, presence, calls)
- Product state: Cloud Firestore (profiles, communities, subscriptions, Whisper Questions, etc.)
- Compute: Cloud Functions (asia-southeast1) — push, sealed delivery, QR, billing, vault
- Shared media / history: Cloudflare R2 + Workers (open-history); Bunny CDN (community/broadcast/stories media)
Deep dive: System architecture.
What this documentation covers next
- Docs home · Quickstart · Glossary
- Privacy model and sealed vs shared matrix
- Delivery architecture and crypto protocols
- Per-feature technical pages (including encrypted calls)
- Threat model, FAQ, and comparisons to WhatsApp, Signal, and Telegram
- Reference tables (retention, subprocessors, limits)