Broadcast Channels
Buzzio Broadcast Channels are publisher feeds, not group chats. Admins post. Followers follow, read, react, and vote on polls. They do not flood the channel with replies.
In plain terms:
- You create a channel with a name, @handle, category, and Public / Unpublic discoverability choice.
- Only admins (up to 5) can compose posts — text, photos, video, voice, and polls.
- Followers get a clean Updates-style feed; engagement is reactions and polls, not comment threads.
- Content uses server-managed encryption so one post can reach up to 100,000 followers.
- Server post history ages out after about 30 days — the feed stays fresh; we are not building a forever archive of every broadcast.
We do not sell broadcast data — not posts, reactions, follower maps, or search indexes. Legal detail: /privacy · /terms · overview: /introduction.
Public search & discovery
How a channel becomes discoverable
At create time, the creator sets the Public channel toggle:
| Setting | Effect |
|---|---|
| Public ON | Eligible for Search channels, category browse, and trending / regional discovery rails |
| Public OFF (unpublic) | Not listed in the open public directory. People reach it via share link, invite, or known handle — not open search |
Only public channels enter Buzzio’s public search index. Unpublic channels are intentionally absent from that catalog.
What is indexed / searchable
Discovery looks at channel directory metadata, not post bodies and not follower identity lists.
| Field | Role in search |
|---|---|
| Name | Full-text / prefix matching |
| @handle | Exact and prefix match (unique, lowercase handles) |
| Description | Matches in free-text search |
| Category | Chip filters: General, News, Sports, Tech, Entertainment, Business |
| Country code | Optional regional rails |
| Search keywords | Normalized tokens derived from name / handle / description |
| Follower count | Popularity ranking for browse modes |
| Trending score | Followers + a recent-activity bonus when the channel posted in the last ~7 days |
| Latest post preview | Short list preview (for UI; search ranking uses channel metadata) |
Not in the public search index: encrypted post bodies, media blobs, individual follower IDs, reaction vote records, or private keys.
How people find channels
- Channels tab → search — dedicated Search channels screen.
- Category chips — browse public channels by topic.
- Trending / regional rails — popular public channels ranked for discovery.
- Share links — deep links and web-style handle URLs open a preview (name, bio, follower count, recent context) → Follow → feed.
- Preview sheet — tap a followed-channel avatar for a quick peek before opening the feed.
Search queries the channel catalog — never a 100K-row follower table.
Admin controls over discoverability
| Control | What it does |
|---|---|
| Public / Unpublic at creation | Primary gate into the open directory |
| Name, handle, description, category, avatar | What appears on previews and in search results |
| Share link / QR | Invite path for unpublic or campaign growth |
| Unfollow / leave (followers) | Stops receiving that channel’s feed on their side |
Making a channel public makes directory fields discoverable by design. It does not mean Buzzio sells the audience or builds ad profiles from who follows you.
Admin posting model
Who can post
| Role | Capability |
|---|---|
| Creator | Owns the channel; is an admin; posts |
| Admins (max 5 total, including creator) | Compose and publish |
| Followers | Read the feed; may react and vote on polls if following — cannot post |
Non-admin writes are rejected. The follower UI has no message input for free posting — by design.
What admins can publish
- Text updates
- Image / video / voice (encrypted media objects; signed access for admins & followers)
- Polls (question + up to 4 options)
Abuse guardrails include a high daily post limit per channel and a 100,000 follower cap per channel.
Moderation
Broadcast Channels are not community forums with member reply queues.
- No follower comment threads and no reply-approval inbox for follower posts (followers don’t post).
- Publishing is admin-authored: when an admin hits send, the post goes through the broadcast pipeline (encrypt → live signal → durable history → optional push to opt-in followers).
- Channel operators remain responsible for what they publish (see /terms). Safety tools such as report flows still apply.
Subscriber interaction limits
| Interaction | Allowed? | What others see |
|---|---|---|
| Post / reply | No (followers) | n/a |
| Emoji reactions | Yes (followers) | Anonymous tallies only |
| Poll votes | Yes (followers) | Aggregate option counts |
| “Who reacted?” list | No public list | Integrity records may exist server-side to stop spam voting |
Supported reactions for product integrity: 👍 ❤️ 😂 😮 😢 🙏 (one reaction per user per post; changing emoji updates the tally).
Followers must follow the channel to interact. That is engagement with a publisher — not a two-way chat graph on the private E2E surface.
Server-managed encryption (not E2E)
The honest headline
Broadcast Channels are not end-to-end encrypted like Buzzio 1-to-1, Whisper, or E2E groups.
They use a server-held data encryption key model — same family of design as Communities / open-history rooms.
How it works
- On channel creation, the server generates a channel encryption key and stores it wrapped under Buzzio’s key-wrapping.
- Authorized clients (admins who post; followers who read) obtain that key after access checks.
- The client encrypts / decrypts text and media with AES-GCM using that key (and a key version for rotation tracking).
- Durable posts land as ciphertext in history batches — not as plain chat documents.
- Servers can decrypt when the product needs it (for example short list previews, moderation/report handling within retention) because Buzzio can unwrap the channel key.
Media uploads are stored as encrypted blobs under a channel-scoped path, with signed upload/download URLs.
How this differs from E2E
| E2E (1-to-1 / Whisper / E2E groups) | Broadcast (server-managed key) | |
|---|---|---|
| Who holds the content keys | Devices of participants | Service holds wrapped channel key |
| Can Buzzio read post plaintext? | No (by design) | Yes, if operating the feature (keys are service-managed) |
| Why | Sealed private conversation | One publish → many devices + shared history window |
| Delete-on-delivery private inbox? | Yes on private 1-to-1 | No — feed needs a shared retention window |
| Operator-blind promise? | Core promise | Not claimed — we say so upfront |
Why this tradeoff exists at scale
- One post, many readers — up to 100K followers cannot each hold a unique E2E session the way a sealed 1-to-1 can.
- Catch-up history — later opens (and late devices) need a consistent encrypted backscroll for the retention window.
- Pull model — followers fetch pages when they open the feed; the service must serve sealed batches without a per-follower re-encrypt storm.
- Product features that need it — list previews, retention prune, optional safety review of stored content still within the window.
We choose scale + honesty over falsely labeling broadcast as E2E.
Security properties that still apply
| Property | What it means here |
|---|---|
| Transport encryption | Client ↔ server and CDN hops ride TLS / signed URL channels |
| At-rest encryption | Post bodies and media are stored as ciphertext under the channel key; keys are wrapped at rest |
| Access control | Key release requires auth + admin or follower relationship; unpublic channel preview requires admin / following / authorized access |
| Media path isolation | Media paths stay under the channel’s broadcast prefix and end as encrypted objects |
| Ephemeral live signal | Live inbox nodes are short-lived delivery signals — not a second permanent plaintext store |
Bottom line: Encryption here protects against casual storage leakage and unauthorized outsiders. It does not mean Buzzio is cryptographically unable to read broadcasts. For that promise, use 1-to-1, Whisper, or E2E groups.
30-day retention
What is retained (during the window)
| Data | Retention idea |
|---|---|
| Post ciphertext batches (text / media references / poll payloads in history) | ~30 days, then pruned from broadcast history storage |
| Open / unsealed post batch still being written | Filtered so messages older than the cutoff drop out |
| Encrypted media referenced by posts | Tied to the same short-lived feed model and channel media pool / boot limits |
| Channel profile (name, handle, description, category, public flag, avatar) | Lives with the channel while it exists |
| Follower relationship (follow + notify preference) | Live while the follow remains — not a 30-day wipe of “who follows” |
| Follower count | Operational display count while the channel lives |
| Reaction / poll integrity records | Kept so tallies and anti-spam voting work for live posts |
| Search index fields for public channels | Directory metadata while public and the channel exists |
| Local device cache | Short-lived cache of recent posts — not a Buzzio cloud inbox of forever |
What is purged around day 30
A scheduled retention job deletes history batches older than the channel’s retention days (default 30). Open message staging is trimmed the same way.
Effect for users: older updates disappear from the shared server feed. Broadcast is a rolling window, not a permanent newspaper archive.
Is retention configurable by admins?
| Today | Detail |
|---|---|
| Product default | 30 days for every new channel |
| Admin UI knob | No — creators do not get a “keep for 90 days” slider in consumer settings today |
Storage boot tiers expand media quota for publishing — they do not reinvent broadcast as multi-year cloud journaling. The feed’s identity remains a short history window.
Other broadcast features
Follower counts (not follower dossiers)
- Channels show a follower count on search results, previews, and settings.
- Counts scale toward 100K.
- Admins cannot download a follower address book. That protects followers and keeps the architecture sane at scale.
Reactions & polls
- Followers react with emoji; UI shows counts.
- Admins can post polls; results are aggregate option counts.
- Uniqueness checks prevent one person from stuffing the ballot — integrity data, not ad data.
Notifications (muted by default)
- On follow, notifications default to off — quiet by design.
- Followers who want alerts opt in.
- Push is built for one topic send per post, not 100K individual blasts. Opt-in pushes may be staggered to reduce thundering herds.
- Payloads prioritize wake / open feed over dumping full post text into notification trays.
Categories
Discovery categories: General · News · Sports · Tech · Entertainment · Business. Creators pick one at create time so search chips work.
Share, QR, and deep links
Admins and promoters can share channel links / QR. Public handles unlock friendly web-style URLs; channel-ID links work for invites either way.
Channel media library
Followers and admins can browse media from the channel feed within what is still available in the retention / download pipeline.
History Boot (storage growth, not encryption change)
Channels start on a freemium media pool. Boot credits add media bytes for a period so growing publishers are not instantly capped. Followers may gift storage to help a channel grow. Boot changes quota, not the server-managed encryption security story.
Freemium create limit
Free accounts may create a limited number of channels; upgrade unlocks more. That is a growth control, not a privacy claim.
Trust cues people see are public profile fields, follower count, category, and consistent @handle — plus Buzzio’s broader account identity model. Aggregate engagement (reactions / polls / follower count) is what admins get today — not a silent dossier of every follower’s private Buzzio graph.
How a post moves
Admin compose
→ Seal with channel encryption key
→ Ephemeral live inbox signal (short-lived)
→ Durable sealed batches in history storage
→ Optional push topic for notify-opt-in followers
Follower opens feed
→ Auth + follow check
→ Fetch key (if authorized)
→ Pull paginated history
→ Decrypt on device for reading
Daily retention
→ Drop batches older than ~30 days
| Layer | Stores post bodies? |
|---|---|
| Profile / follows / counters | No — metadata only |
| Live inbox | Ephemeral signal only |
| Object history | Yes — sealed ciphertext batches |
| CDN media | Encrypted media objects |
| Device cache | Short cache only |
Designed for ~100K followers / channel with pull-based reads — cost scales with people who open the feed, not with blind fan-out of every byte to every follower.
How Broadcast fits the Buzzio promise
| Surface | Secrecy model | Server history |
|---|---|---|
| 1-to-1 / Whisper / E2E groups | End-to-end | Minimal / delete-on-delivery style |
| Broadcast Channels | Server-managed encryption | ~30-day rolling feed |
| Communities | Server-held encryption | Longer durable room history |
Same rule everywhere: maximum secrecy where the product is a sealed conversation; transparent extra storage where the product is a shared feed; never a data-broker model.
Summary
Broadcast Channels are one-to-many publisher feeds with optional public search, admin-only posting (up to 5 admins), and follower engagement limited to anonymous reactions and poll tallies. Encryption is server-managed for scale — honestly not E2E. Posts roll off after ~30 days. Follower counts are shown; follower address books are not. Notifications default to muted. Cap: 100,000 followers per channel.
Related: /introduction · /one-to-one-chat · /groups · /communities · /privacy · /terms