Manage roles & permissions

Build from least privilege

Give every member the base user role. Add narrowly scoped roles for moderators, channel managers, event hosts, asset designers, or integrations. Put more influential roles earlier in the order because hierarchy checks and public styling depend on position.

Administrative permissions

Grant only the capabilities a role needs. manage_roles is especially sensitive because it controls access design; the server prevents an actor from granting a permission they do not hold, but a broadly privileged role can still make consequential changes.

Channel permissions

Channel rules are role-name arrays, not conventional deny-by-default allowlists. !role entries deny first; positive role names grant; with no positive names, everyone not denied is allowed. The role name owner bypasses these rules, but the administrator permission does not. Review view first, then send, then moderation actions.

Self-assignable roles

Use self-assignment for interests, notifications, colors, or opt-in spaces—not staff authority. The protected owner, admin, and user roles cannot be self-assignable. When a user adds/removes a self role, the server refreshes their channel list immediately.

Change safety

Before deleting or renaming a role, locate channels and users that refer to its name. Keep at least one recoverable owner account. Review the audit log after hierarchy changes and test access with representative accounts.