Motivation
Buzz is increasingly used as a Slack alternative by non-software, non-technical organizations (creative agencies, ops teams, etc.). These users expect a clean, curated experience where the entire topology — agents, compute, experiments — is set up and owned by an admin, and where non-admin members cannot accidentally perturb it.
Today every community member can open the Agents tab and the agents / compute / experimental settings sections, and there is no admin-managed boundary keeping the agent + compute surface curated.
Proposed solution
Add a per-community, per-role capability policy, configurable by the community owner. Default: current behavior (everything open) — no breaking change for existing communities.
Capabilities the owner can toggle per role:
- Enter the Agents tab
- See the agents / compute / experimental settings sections
- Create/manage agents (relay-enforced)
- Usage — @mention shared/owner-created agents — stays open by default, so members can still use the agents the admin has set up
Implementation (Nostr-idiomatic)
Following the project convention of modeling operations as Nostr events rather than new HTTP endpoints:
- A new owner-authored community policy event kind (alongside the
kind:39000 metadata family), carrying the role → capability map.
- Desktop reads it and filters the Agents tab +
SettingsView sections (SettingsView.tsx) by the viewer's role. SettingsView currently hardcodes sections: ["agents", "compute", "experimental", "mobile", "updates"].
- Relay reads it and enforces at ingest — reject member-authored agent-creation kinds (
30177 Managed Agent, 30176 Team) when that capability is off. Agent definitions are already owner-authored by design (buzz-core/src/kind.rs).
Design constraint
Relay enforcement requires the auth-pipeline mode. In pure-Nostr mode every NIP-42 connection receives the full scope set (buzz-auth/src/scope.rs), so member restriction is not enforceable there — this should be documented as part of the feature.
Acceptance criteria
Motivation
Buzz is increasingly used as a Slack alternative by non-software, non-technical organizations (creative agencies, ops teams, etc.). These users expect a clean, curated experience where the entire topology — agents, compute, experiments — is set up and owned by an admin, and where non-admin members cannot accidentally perturb it.
Today every community member can open the Agents tab and the agents / compute / experimental settings sections, and there is no admin-managed boundary keeping the agent + compute surface curated.
Proposed solution
Add a per-community, per-role capability policy, configurable by the community owner. Default: current behavior (everything open) — no breaking change for existing communities.
Capabilities the owner can toggle per role:
Implementation (Nostr-idiomatic)
Following the project convention of modeling operations as Nostr events rather than new HTTP endpoints:
kind:39000metadata family), carrying the role → capability map.SettingsViewsections (SettingsView.tsx) by the viewer's role.SettingsViewcurrently hardcodessections: ["agents", "compute", "experimental", "mobile", "updates"].30177Managed Agent,30176Team) when that capability is off. Agent definitions are already owner-authored by design (buzz-core/src/kind.rs).Design constraint
Relay enforcement requires the auth-pipeline mode. In pure-Nostr mode every NIP-42 connection receives the full scope set (
buzz-auth/src/scope.rs), so member restriction is not enforceable there — this should be documented as part of the feature.Acceptance criteria
30177/30176rejected relay-side with a clear "admin-only" error in auth-pipeline mode.