Communities
Buzzio Communities are shared servers — not private 1-to-1 chats and not small Groups. They give you categories, text channels, roles, events, invites, and moderation, with an honest label: not end-to-end encrypted. Message text is stored in plaintext on Buzzio servers so history and multi-device continuity work for thousands of members.
In plain terms:
- You create a community (a server) with a name, optional password, and optional join approval.
- Under it live categories → text channels (open or password-locked).
- Roles — Everyone, Creator, Creator Admin, and custom roles — control who can invite, moderate, manage structure, and post.
- Events let members mark Interested; location can be text, a link, or a community channel.
- Content is plaintext on Buzzio servers so late joiners and moderation work.
We do not sell community data — not channel messages, member lists, role maps, event RSVPs, invite tokens, or audit logs. Legal detail: /privacy · /terms · overview: /introduction.
What’s inside a community
Communities are separate from Groups. A Group is one chat room. A Community is a home with many text channels, roles, and events — Groups are not placed inside Communities.
Inside a community you can:
- Organize the sidebar with categories and text channels (open, or locked with a password)
- Chat with messages, pins, and media in those channels
- Assign roles so people can invite, moderate, or manage rooms
- Review members, bans, and join requests
- Create events where members mark Interested
- Share invites (including temporary ones) and review audit logs if you have permission
What seeds on create
| Entity | Default |
|---|---|
| Category | Welcome |
| Channel | #general — default, open, inside Welcome |
| Role | Everyone with safe invite / view defaults |
Channels without a category appear under an uncategorized area in the hub. There are no voice channels — text channels only.
Communities vs Groups
| Communities | Groups | |
|---|---|---|
| Structure | Server → categories → many channels | Single room |
| Typical size | Clubs, schools, creators (up to 10k) | Circles / teams (smaller cap) |
| Crypto | Server-held community / channel keys | E2E sender keys or open-history keys |
| Roles | Discord-style permission matrix | Super Admin / Admin |
| Events | First-class community events | Not this product |
Use Groups when the product is one conversation. Use Communities when the product is a home with rooms, roles, and calendars.
Encryption model (plaintext shared rooms)
Communities are open shared rooms. Message text is stored in plaintext on Buzzio servers. Media is stored on CDN without encryption. Password channels still use a join password — that password gates who can enter, it does not encrypt the messages.
Honest line: Communities are not operator-blind E2E. Buzzio can read community messages so history, mentions, moderation, and future bots work. If you need Buzzio-blind message bodies, use 1-to-1, Whisper, or E2E Groups.
Membership still gates who can send and load history. Leave, kick, or ban stops future access.
How community keys work for members
| Moment | What happens |
|---|---|
| Create community | Creator receives the community key so they can start encrypting |
| Join (invite / password / approval) | After membership succeeds, the member can obtain the community key |
| Open channel message | Encrypt/decrypt with the community key |
| Password channel | Member must unlock the channel with its password; then they get that channel’s dedicated key |
Membership is the gate. Leave, kick, or ban → key fetch stops for that account.
Per-channel keys vs the community key
| Channel visibility | Key used for channel content |
|---|---|
| Open | Shared community key |
| Password | Dedicated channel key |
Converting a channel to password:
- Generates a new channel key
- Resets channel membership to the editor (others must re-join with the password)
- Open → password is a real key boundary, not a cosmetic lock
Switching password → open returns that channel to the community key model.
Rotation on membership change
The community key is not automatically rotated on every leave, kick, or ban.
| Event | Key behavior |
|---|---|
| Member joins | Gains access to the current key(s) their membership allows |
| Member leaves / kicked / banned | Server stops issuing keys via membership checks |
| New key created | Community create; or new key when a channel becomes password-locked |
Cutting membership stops cloud key fetch and future authorized sync. A former member who already cached a key on a compromised device is a device-security problem — we do not pretend a leave event rewrites every historical ciphertext. Treat bans and device discipline as part of community hygiene.
Roles: Everyone, Creator, Creator Admin, custom
| Role | Persistent? | Assignable? | Default power |
|---|---|---|---|
| Creator | Virtual (always the community creator) | No | All permissions, always |
| Creator Admin | Yes | Yes (creator-gated) | All permissions; cannot remove the creator |
| Custom roles | Yes | Yes | Whatever you toggle |
| Everyone | Yes | Implicit — all members | Invite people, view audit logs, view members (tunable) |
How custom roles work
Each custom role stores a name, optional color, display order, a map of permissions, and which channels the role may edit when it has channel-edit rights.
Setup templates at create (gaming, school club, study group, friends, artists/creators, local community, or build your own) are shortcuts for name and vibe — they use the same permission engine.
How permissions resolve
Buzzio Communities use additive OR, not Discord-style deny-overrides:
- Creator → every permission.
- Else Creator Admin / administrator grant → every permission (cannot remove the creator).
- Else merge Everyone + all assigned custom roles — any grant wins.
- Optional community flag can hide the member list from non-privileged members.
Display order is sort only. Higher position does not override lower roles the Discord “higher role wins” way. Grant carefully: permissions accumulate.
Channel-level permission overlays
Separate from community roles, each channel can restrict:
- Who can view — role lists (open channels default to Everyone; password channels start restricted)
- Who can send/react — per-action grants (text, GIF, sticker, image, video, voice, react)
Administrators with the community administrator grant bypass channel-specific restrictions (including seeing password channels they’re entitled to by that grant).
When a role is deleted
You cannot delete Everyone or Creator Admin. Deleting a custom role strips that role from members immediately — they keep Everyone defaults and any other roles still assigned. Treat “delete role” as removing a grant bundle, not rewriting history.
Full permissions list
Community-level permissions
| Permission | What it allows |
|---|---|
| Create channels | Create new text channels |
| Edit channels | Edit name, visibility, settings for allowed channels (channel creators can always edit theirs) |
| Create categories | Create and organize categories |
| Create events | Schedule community events |
| Manage events | Edit/delete events created by others |
| View audit logs | Read the community audit log |
| Invite people | Share invite links |
| Ban & remove members | Remove or ban members |
| Delete other messages | Delete others’ messages for everyone in a channel |
| Pin and unpin messages | Pin/unpin in channels |
| Can tag | Use @everyone, @here, @role, @username style tags |
| Bypass slow mode | Ignore restricted messaging for new members |
| Manage roles | Create roles and assign them |
| Modify description | Edit community description |
| Modify rules | Edit community rules text |
| View member list | See full member directory |
| Create temporary invite links | Time-limited invites |
| Create temporary channel passwords | Temp passwords for locked channels |
| Administrator | All permissions + bypass channel restrictions; cannot remove/ban the creator |
Everyone defaults (out of the box): invite people, view audit logs, view members.
Grouped in the role editor: Structure · Moderation · Invites (plus the separate administrator toggle).
Channel message permissions
| Permission | UI label |
|---|---|
| Send text | Send text messages |
| Send GIF | Send GIFs |
| Send sticker | Send stickers |
| Send image | Send images |
| Send video | Send video files |
| Send voice | Send voice messages |
| React | React to messages |
Creator-only action
| Action | Who |
|---|---|
| Assign Creator Administrator | Creator only |
Events: Interested RSVP & location types
What an event stores
| Field | Purpose |
|---|---|
| Title, description | What / why |
| Start / end | Schedule window |
| Frequency | None, daily, weekly, or monthly |
| Location type + location fields | Where (see below) |
| Optional cover image | Visual |
| Authorship / ordering | Who created it, when, sort order |
| Interested count | Denormalized RSVP tally |
Edit/delete: event creator with create-events permission, or anyone with manage-events.
Location types
| Type | Meaning | Privacy note |
|---|---|---|
| Text | Free-form place / address / informal note | Visible to community members who can see the event — treat addresses as shared club info |
| Link | Virtual meeting (http/https URL) | Same member visibility; don’t put secret join codes in events visible to a large room |
| Channel | Meet in a Buzzio channel (#…) | Points inside the community — no external address leak |
“Interested” RSVP
| Step | Behavior |
|---|---|
| Member taps Interested | Records interest for that event |
| Counter | Interested count updates atomically |
| Lists | Members can see who is interested |
RSVP visibility & privacy
- Not anonymous. Any community member can see who marked Interested.
- Outside the community: RSVPs are not a public web directory.
- Marking Interested shares your Buzzio identity with fellow members, not with advertisers. We do not sell RSVP graphs.
Other community features
Channel categories
Full create / rename / reorder. Default Welcome + #general pattern matches familiar muscle memory.
Rules & onboarding
| Feature | Behavior |
|---|---|
| Community rules text | Editable with modify-rules; shown from hub / settings |
| Per-channel rules | Optional channel-specific rules |
| Setup | Name, optional community password (≥4 chars), require-member-approval |
| Welcome UI | Empty #general shows a welcome view; post-create hub banner |
| Forced “accept rules” before join | Rules are visible guidance — not a hard gate |
Join gates
| Gate | Purpose |
|---|---|
| Invite token / QR / deep link | Primary join path |
| Optional community password | Checked at join |
| Optional approval queue | Join requests until an authorized member approves — no encryption key until approved |
| Channel password | Separate lock + channel key |
| Bans | Blocked from rejoin |
There is no community government-ID check. Access = invite + optional password + optional approval.
Discovery & search
| Feature | Present? |
|---|---|
| Public community directory / browse marketplace | No |
| Join by community ID + invite/password | Yes |
| Invite deep links / QR | Yes |
| In-hub channel / category search | Yes |
| Member list / mention search | Yes |
Discovery is intentional (share a link), not a sold public catalog of every community.
Member limits & scale
| Limit | Value |
|---|---|
| Hard member cap | 10,000 |
| Soft “large community” tip | ~5,000 — recommend tags-only notifications; admin decides |
Join / approve fail when full.
Restricted messaging (slow mode)
Levels: none · low · medium · high · highest — rate-limits new members. Bypass with bypass-slow-mode permission.
Notifications
Per-member level: all · mentions · none. Community can push tags-only (especially useful near the large-community tip).
Channel hardening extras
Per channel (where enabled): screenshot protection (Secure View–class hardening) and vanish mode with TTL. OS screenshot blocking has platform limits; harden, don’t promise physics.
Audit logs
Membership and moderation actions can land in audit logs for members with view-audit-logs. Oversight for organizers — not an advertising feed.
Freemium create limits
Free accounts may own 1 active community at a time. Deleting it frees the slot. Buzzio Premium unlocks unlimited active creates. Messaging itself is unlimited on free.
Metadata honesty
| Surface | Readable channel archive for Buzzio? | Durable admin state? |
|---|---|---|
| Community open channels | Encrypted under server-held community key (feature needs it) | Yes — members, roles, bans, invites, events, audit |
| Password channels | Encrypted under channel key; still server-held wrap model | Yes — plus channel membership |
| After leave / ban | No further key issue to that account | Membership & ban records as needed to run the server |
“Zero metadata” for private 1-to-1 is a sealed conversation claim. Communities necessarily keep membership, roles, events, and invites — that is how a multi-channel home runs. It is administration, not a sold social graph.
How to choose
| If you want… | Choose |
|---|---|
| One private circle / trip room | Groups |
| Operator-blind message bodies | E2E Groups or 1-to-1 / Whisper |
| Many channels, roles, events, moderation | Communities |
| Late joiners who can read shared channel history | Communities (server-held keys) — by design |
| A locked topic inside the same server | Password channel (separate channel key) |
| Announce to followers without chat chaos | Broadcast Channels |
Summary
Communities are Discord-shaped: community → categories → text channels — separate from Groups. Crypto is honest: server-held community key for open channels; dedicated key for password channels — not E2E. Keys are membership-gated; the community key is not auto-rotated on every leave. Roles include Everyone, Creator, Creator Admin, and custom roles with additive permissions. Nineteen community permissions plus per-channel send/react overlays are enumerable. Events support Interested RSVP with locations as text, link, or #channel. Join by invite / ID, optional password and approval; no public marketplace dump. Hard cap 10,000 members, with slow mode, tags, and audit logs for real moderation.
Related: /introduction · /groups · /broadcast-channels · /privacy · /terms