Groups
Buzzio groups are for friends, teams, trips, and circles that need more than a 1-to-1 thread — without pretending every room needs the same secrecy model.
At create time you pick two axes:
- How history works — end-to-end (E2E) or open-history
- How long the group lives — permanent or temporary (up to 30 days)
That gives four real products:
| Permanent | Temporary | |
|---|---|---|
| E2E | Ongoing private group; we can’t read messages; new joiners don’t get a full old archive | Same E2E privacy — then the group ends on a timer |
| Open-history | Shared encrypted backscroll for members (including later joiners) | Shared history while alive, then full wipe when the timer ends |
We do not sell group messages, member lists, invite tokens, or open-history archives. Legal detail: /privacy · overview: /introduction · 1-to-1 baseline: /one-to-one-chat.
The four group types
1. Permanent E2E group
Ongoing private circle. Message bodies are end-to-end encrypted. Buzzio relays ciphertext for catch-up, then purges relay buckets. Readable history lives in the locally encrypted database on each member’s devices. New people who join later get keys for future traffic — not a full archive of the past.
Best for: close friends, family, private teams, sensitive circles.
2. Temporary E2E group
Same encryption model as permanent E2E — plus a hard lifetime (1 hour → 30 days). When the window ends, the group is deleted by design: server group state cleaned, members notified, local chat wiped.
Best for: weekends, trips, exams, short projects, anything that should not sit in everyone’s group list forever.
3. Permanent open-history group
Shared room with durable plaintext history. Later joiners can scroll past messages. Text is stored on Buzzio servers so history delivery works across members and devices. That is not E2E — and we say so upfront.
Best for: clubs, classes, long-running projects, groups that onboard people mid-way.
4. Temporary open-history group
Open history while the group is alive, then expiry deletes the group and wipes open-history messages, keys, and media for that room.
Best for: events and pop-up communities that still need “catch me up” history during the window.
E2E groups vs open-history groups
| E2E | Open-history | |
|---|---|---|
| Encryption model | Sender keys per member (Signal-style group crypto) | Shared AES-256 data encryption key, held by the service for the feature |
| Can Buzzio read message bodies? | No | Service holds keys needed to unwrap content for the feature |
| Where readable history lives | Member devices | Durable server history (encrypted at rest) + devices |
| Server relay / retention | Short catch-up buckets (~5 days), then purged | Default history on the order of ~365 days (plan / media-pool limits apply) |
| New joiner backscroll | Does not get a full old E2E archive | Can load shared past messages |
E2E: how group keys work
Buzzio E2E groups use sender-key group crypto on top of your existing 1-to-1 Double Ratchet sessions:
- Each member generates their own sender key material for that group on device.
- They distribute that material to other members as encrypted control messages — protected by pairwise E2E, not as plaintext on the wire.
- Group messages are sealed with the sender’s chain; peers who received that distribution can decrypt.
- Servers see ciphertext + routing, not readable text. After catch-up windows, durable readable E2E archives are not kept.
What that means for you: adding someone distributes current keys so they can join the conversation going forward. It does not reconstruct an open cloud transcript of everything said before they arrived.
Open-history: how the shared key works
- The creator provisions a data encryption key for the group.
- The server stores a wrapped copy so current members can obtain it to encrypt and decrypt room content.
- Text and media are encrypted under that key before durable storage.
- History APIs page encrypted history back to authorized members — that is the product: shared continuity.
Honest line: open-history is encrypted at rest with keys Buzzio holds for the feature. It is built for rooms, not for “Buzzio is blind forever.”
Who can decrypt history?
| Mode | Who can decrypt |
|---|---|
| E2E | Members who received the relevant sender-key distributions. New members unlock future traffic; past ciphertext is not an open archive for late joiners. |
| Open-history | Any current member (and the service, by design of the shared key). Removed members lose server key access for that group; leftover local cache on a left-behind device is a device-security concern, not a Buzzio cloud re-share. |
Permanent vs temporary
Temporary is not a soft “maybe delete someday.” It is a scheduled lifetime.
Expiry options
At create time you choose a duration preset:
1h · 2h · 6h · 12h · 1d · 2d · 3d · 7d · 10d · 14d · 20d · 30d
(max 720 hours / 30 days)
Delete runs when the earliest of these hits: the scheduled expiry, an optional custom destruct time, or dissolve/delete by an authorized role. Same duration options apply to temporary E2E and temporary open-history.
What gets wiped when a temporary group expires
- Members get a push so clients can react.
- Open-history: durable messages, keys, and feature media for that group are wiped.
- Group document and related relay / receipt state are removed; group image cleaned.
- Clients clear local group chat for that room so the conversation does not linger as a normal thread.
Permanent groups have no auto-expiry. They live until dissolve/delete by authorized roles. Permanent join hygiene includes a join-attempt cap (3) and banned members who cannot self-rejoin after admin removal.
Changing type after create
Encryption mode (E2E ↔ open-history) and permanence (permanent ↔ temporary) are chosen at creation. There is no “switch history mode later” path — pick the room that matches the job up front.
Encryption behavior per mode
E2E (permanent or temporary)
| Topic | Behavior |
|---|---|
| Key management | Each member holds their own sender-key chain; distribution rides pairwise E2E |
| Member add | New member is added to membership; peers distribute current sender keys; new member gets future message access |
| Member remove | Removed from members / admins, added to banned list; removal signal; local wipe for temporary removals. Membership gate stops future access; historical sender keys already on other devices are not reinvented on every remove |
| Old messages after remove | Ciphertext that already landed on other members’ devices remains under those devices’ local history rules. The removed person is cut off from new membership and relay |
| Server archive | No durable readable E2E transcript for Buzzio operators |
Open-history (permanent or temporary)
| Topic | Behavior |
|---|---|
| Key management | Shared encryption key provisioned for the group; members fetch it while membership is valid |
| Member add | New member can decrypt stored history with the same key — that is the point of open-history |
| Member remove | Membership check fails for key / history APIs; the shared key itself is not reinvented per leave |
| Old messages after remove | Server history stays available to remaining members (until retention / group delete). Removed users no longer qualify as members for key fetch |
| Server archive | Yes — encrypted history retained so the room works (~365-day default class retention, subject to plan / media pool) |
Delete-for-everyone windows
- Open-history delete-for-everyone window is short (on the order of a few hours).
- E2E / relay group delete coordination uses a longer coordination window (on the order of a day) for undelivered / peer cleanup.
Deletes are coordinated membership tools, not a Buzzio-readable undo log.
Vanish and Secure View in groups
These names match 1-to-1 for product clarity — but group implementation is not identical to the mutual 1-to-1 handshake.
Secure View / screenshot protection
| Groups | 1-to-1 | |
|---|---|---|
| How you turn it on | Create-time Secure View setting | Mutual request / agree / reject / off |
| Pending expiry | N/A (static group setting) | Pending ~2 hours |
| While chat is open | Screen-security hardening on Android; platform limits elsewhere | Same class of OS / in-app mitigations while mode is active |
| Modes | Available when creating E2E and open-history groups | Per private conversation |
Trust note: iOS / web cannot always fully block OS screenshots the way Android can. Buzzio detects and mitigates in-app where possible; treat capture protection as hardening, not a physical law.
Vanish mode
| Groups | 1-to-1 | |
|---|---|---|
| Availability | Create-time option on E2E permanent / temporary groups | Mutual / session-style vanish |
| Open-history | Not available | N/A |
| TTL options | 5s · 1m · 5m · 1h · 6h | Same order of magnitude in product |
| Timer start | Group vanish schedules from local handle time for messages under the group TTL | Countdown after seen |
| Scope | Group-wide TTL setting for that E2E room | Per chat / mutual session |
View-once media in groups
Group view-once media uses a dedicated viewer with screen security, a short auto-clear open window (~20s), and no “opened” receipt pinged to the sender the way some 1-to-1 once-view flows behave — to reduce notification side-channels in multi-member rooms.
Roles: Super Admin vs Admin
| Action | Super Admin | Admin | Member |
|---|---|---|---|
| Add members | Yes | Yes | No |
| Remove members (not Super Admin) | Yes | Yes | No |
| Remove / demote Super Admin | No | No | No |
| Promote / demote Admin | Yes only | No | No |
| Transfer Super Admin | Yes (if other admins exist, transfer must go to an existing admin) | No | No |
| View / share invite link | Yes | Yes | No |
| Regenerate invite token | Yes only | No | No |
| Change join password | Yes only | No | No |
| Edit description & rules (≤ ~300 words) | Yes only | No | No |
| Upload / change group avatar | Yes | Yes | View |
| Approve join requests (if approval on) | Yes | Yes | No |
| Pin / unpin messages | Yes | Yes | No |
| Dissolve / delete when sole remaining | Yes | Leave path; sole-member delete gated to Super Admin in UI | Leave |
| Leave group | Yes (with transfer rules if others remain) | Yes | Yes |
| Send when only-admins-can-send is on | Yes | Yes | Read / react only |
| See full member list when members are hidden | Yes | Yes | Admins only |
| Local clear chat / lock / media visibility / read-receipt prefs | Per-device | Per-device | Per-device |
History mode, permanence, vanish, and Secure View are set when the group is born. Day-to-day power is membership, roles, invites, pins, and moderation gates.
Invite links and join security
Invite links carry group id + invite token + display name encoding — not encryption keys and not your 12-word phrase.
Regenerating the token invalidates old links. Share links like door codes: treat regeneration as the emergency lock change.
| Control | What it does |
|---|---|
| Optional join password | Stored as a hash (not a plaintext password dump). Min length enforced at create (from 4 chars upward). |
| Require member approval | Join requests queue for Super Admin / Admin approval |
| Temporary groups | One-time invite usage per user class hygiene |
| Permanent groups | Join attempt cap (3); admin-removed users land on banned list and cannot self-rejoin |
| Member limit | Up to 500 members per group |
Invites are for membership, not for bypassing E2E key distribution or grabbing someone else’s private keys.
Everyday group features
| Feature | In groups today |
|---|---|
| Replies | Yes — thread context on messages |
| Reactions | Yes — shared emoji state for that message |
| Pinned messages | Admin / Super Admin; durations on the order of 24h / 7d / 30d; visible to members |
| Starred messages | Local on device |
| Forward | Available into group flows with type limits |
| Media gallery | Media, links & docs browser for the room |
| Read receipts | Per-device preference |
| Only admins can send | Announcement-style rooms |
| Hide member list from members | Privacy for larger / sensitive membership maps |
| Lock group | Local device lock for opening that chat |
| Private storage timer | Local auto-delete hygiene |
| Report | Safety tool |
| Batch remove / ban | Admin moderation |
| Removal history | Audit-style membership change visibility for operators of the group |
At larger member counts (≥ ~100), per-message push wake may be batched for scale — members still get messages via normal sync paths. The privacy model does not flip because of push batching.
Groups stay the focused small/mid room. For Discord-scale roles, channels, and events, see Communities.
Metadata honesty
| Surface | Readable message archive for Buzzio? | Durable membership / admin state? |
|---|---|---|
| E2E groups | No readable transcript of what was said | Yes — members, roles, bans, invites so the group can run |
| Open-history groups | Encrypted history under server-held keys (feature needs it) | Yes — plus history / media infrastructure |
| After temporary expiry | Group content path wiped per delete pipeline | Expiry bookkeeping ages out |
“Zero metadata” for 1-to-1 (no durable who-talks-to-whom graph when nothing is undelivered) is a private 1-to-1 claim. Groups necessarily keep membership and roles — that is administration, not a sold social graph for ads.
How to choose
| If you want… | Choose |
|---|---|
| Maximum privacy from the operator | E2E permanent or temporary |
| New people able to read past context | Open-history |
| The room should die with the event | Temporary (either encryption mode) |
| Ongoing private club | Permanent E2E |
| Ongoing shared room / onboarding | Permanent open-history |
| Screenshots harder + short local trail | E2E + Secure View / Vanish at create |
Freemium create limits
Free accounts may own 1 active privacy (E2E) group and 1 active Open History Group at a time. Leaving or dissolving frees the slot. Buzzio Premium unlocks unlimited active creates. Messaging itself is unlimited on free.
Summary
Groups offer four real modes: E2E or open-history × permanent or temporary. E2E groups use sender-key crypto; Buzzio cannot read message bodies; relay catch-up is short (~5 days), not a cloud inbox. Open-history groups use a server-held key for shared encrypted continuity — honestly labeled. Temporary groups use concrete timers up to 30 days, then wipe. Vanish and Secure View are create-time controls (Vanish on E2E; Secure View on both). Super Admin owns critical settings and invite regeneration; Admins run day-to-day membership and pins. Invite links carry tokens, not keys; optional password hash, approval, bans, and a 500-member cap.
Related: /introduction · /one-to-one-chat · /communities · /privacy · /terms