Give an external stakeholder scoped guest access
Project lead, workspace owner · Set up the workspace
Why this matters
Getting this wrong means an external party sees another client's channel, or lands in your internal workspace with full member rights. The failure is confidentiality, it is silent, and it is not recoverable by deletion — the event log keeps what was read.
Your team decides
Buzz gives you two blunt controls — community membership and private channels — and a guest role that exists in the model but has no product surface. The steps below are principles to work through in order, not clicks; the answers are policy your team writes down before anyone outside your organisation is let in.
Steps at a glance
1. Decide whether this person needs guest access or full membership
The principle: a full member is not a scoped guest. A community member sees every open channel, the member directory and everything search reaches; there is no partial membership in between. So the first question is not "how do I add them" but "does this person belong inside the boundary at all".
Agree the rule that separates the two cases — for example, a client sponsor who needs one status channel is a guest; a seconded specialist working across the engagement is a member — and agree your default when a case is unclear. The conservative default is isolation: if in doubt, the external party does not enter your internal community at all.
What we know today
Membership is the only content gate in Buzz. The guest role exists in the underlying model — it is one of the roles the CLI accepts when adding a member — but nothing in the desktop app issues or scopes it, and no source explains what a guest can and cannot see. Re-verified against source at v0.5.20, 2026-08-26; nothing in v0.5.15–v0.5.20 moved the scoping model.
2. Determine what they must be able to see, and what they must not
The principle: scope is decided per surface, not per channel. Messages are the obvious content; the canvas, shared media, threads and search results carry as much, and an external person's search reaches as far as their membership does.
List the channels this stakeholder needs, and check each for the three things people forget: what the canvas holds, what has been uploaded, and what a search for the client's name returns from inside that channel. Decide whether your workspace keeps a standing "externally visible" channel pattern, so that the decision is made once per engagement structure rather than once per guest.
Remember that what is read cannot be un-read — see Everything is a signed event.
3. Issue the narrowest access your build actually supports
The principle: grant the smallest thing that works, and prefer a boundary that holds by construction over one that holds by configuration.
In current builds that gives you three options, from safest to least safe:
- A separate community per external party. Full isolation by construction: the stakeholder is a member of a community that contains only what they may see. This is the safest answer available today and the one to reach for with client material.
- A private channel in your community. Hidden and invite-only, with the invitation issued by an owner or admin rather than any member — see Create a channel and add members. The stakeholder still becomes a community member, so every open channel is visible to them; only use this where nothing open would matter.
- The guest role via the CLI. It exists, it is not documented, and its scope is unverified. Do not use it for real access until you have tested exactly what it grants in your build (step 4).
Whichever you choose, the workspace owner is the only party who can grant or remove community-level access, so the owner is in the loop by design. Write the option you chose, and why, into your team's policy — including the plain statement that no user-facing guest mechanism exists, if that is still true when you read this.
4. Verify the scope from the guest's side before they log in
The principle: the first test of a confidentiality boundary must never be a real stakeholder.
Create a test identity that holds exactly the access you intend to give — a fresh keypair, added the same way the stakeholder will be — and look at the workspace through it: the channel list, the member directory, a search for a term that only appears in a channel they should not see. Only when the test identity sees what you intend, and nothing more, does the real person get access. Keep the test identity; you will use it again at every re-check and whenever a build changes the access model.
5. Plan the removal before you grant the access
The principle: access that has no planned end is permanent by default.
Agree, before granting, what ends the access (project close, a date, a role change on either side), who removes it, and how the removal is evidenced — a message in the channel is a signed, durable record, so make the removal one. Check whether access in your build expires on its own; assume it must be revoked manually until proven otherwise, and put the date in whoever's calendar owns the removal.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026