Control
Your community. Your rules.
Roles, permissions and moderation are built into the structure. Set them for the whole Nexus, then override them for one category or Space.
| Role | View | Send | Invite | Moderate | Manage | Admin |
|---|---|---|---|---|---|---|
| Owner | Allowed | Allowed | Allowed | Allowed | Allowed | Allowed |
| Moderator | ||||||
| Member | ||||||
| Newcomer | ||||||
| Aero | Never grantable | Never grantable |
What you can do
01
Roles & permissions
Grant exactly what each role can do.
02
Category & Space overrides
Different rules for different rooms.
03
Moderation
Time out, kick and ban, gated by role.
04
Audit history
A record of moderation and permission changes.
In practice
Newcomers, safely onboarded
A Newcomer role can read and post in Community but cannot see the Development category. Moderators can time people out; only the Owner manages roles. Every action lands in the audit history.
Roles that actually mean something
Roles are where Ballastra’s permission system starts. A role carries a set of permissions and is assigned to members, so "moderator", "builder", "new member" and "owner" behave differently without anyone hand-tuning individual members.
Permissions can be overridden per category and per Space. That is the mechanism that lets one community host a public category and a members-only category under the same roof — broad by default, narrow where it needs to be, all defined once.
Moderation: mute, remove, review
Moderation tools sit inside the Nexus: mute, remove and ban, each available at the level the situation calls for, and every moderation action recorded so a team can review what happened and who did it. An audit trail turns moderation from he-said-she-said into a clear record.
Paired with member management — seeing who is in the community and what they are up to — this is the operational layer that lets a community grow beyond its first dozen people without descending into chaos. The tools exist where the community is, not in a separate pane.
Aeros: automation with guardrails
Developers build Aeros, Ballastra’s bots, in the developer portal. Installing an Aero into a Nexus gives it a managed role, which means the ordinary permission system applies to it unchanged. An Aero can never hold the permissions that manage the Nexus, its roles or its Aeros — automation is bounded by the same rules as people.
That guardrail matters for trust: a community can experiment with automation without handing a bot the keys to the community. The permission model is one system for members and Aeros alike, which keeps communities predictable as they grow more sophisticated.
Structure over guest list
The most common failure of a growing community is not being too big — it is being structureless. Control on Ballastra is designed so that the structure comes first: categories, roles, per-Space permissions and moderation are part of building a Nexus, not afterthoughts.
That is the difference between a community that grows into something unmanageable and one that grows into something people stay in. The tools for staying organised are available from the first member, and they scale to the thousandth.
Common questions
Roles carry a set of permissions and are assigned to members. Permissions can be overridden per category and per Space, so a role can be broad in one part of a Nexus and narrow in another.
Members can be muted, removed or banned, and moderation actions are recorded so a team can see what happened and who did it.
No. An Aero receives a managed role when installed, so ordinary permissions apply to it — and it can never hold the permissions that manage the Nexus, its roles, or its Aeros.
Build the community you want to run.