Manage channels

Plan the structure

Start with fewer channels than you think you need. Use text for continuous conversation, forum channels when topics need their own lifecycle, voice for live rooms, and separators only to make sections easier to scan. A separator’s size controls the UI padding or empty space around it, so use larger values to create a stronger visual break between sections.

Internal names are protocol identifiers, so keep them stable, lowercase, and concise. Use display_name for friendlier presentation. Renaming a channel can move its durable storage paths; do it deliberately and verify clients refresh.

Set access

For every channel, decide who can view, send, manage messages, react, pin, and create threads. Rules are arrays of role names: positive names grant, !role denies first, and an array with no positive names allows everyone not denied. Only the role name owner bypasses channel rules; the administrator permission does not. Test every rule with representative accounts.

Common patterns:

• Announcements: everyone can view; staff can send.
• Staff room: only the staff role can view and send.
• Read-only archive: let everyone view and set send to ["owner"] so only the owner bypass/role can send.
• Forum: members can view/send/create threads; moderators can pin and manage.

Control pace and retention

slow_mode_cooldown is measured in seconds and limits how frequently one user posts; owner/admin roles and manage_server bypass it. max_message_age is stored and returned but is not currently enforced by any cleanup path. A zero slow-mode value removes that override.

Channel changes are audited and immediately refresh connected clients. Deleting a channel is destructive: back up first when its history matters.