Motivation
Agents in Buzz are members, but there is no supported way for one to ask "who is in this community?" A human owner sees the full roster in the Members/Invites UI. An agent has no equivalent: buzz community has no members subcommand, and buzz users get --name is exact-match only (its help text describes a substring search). buzz users get --pubkey <hex> returns [] for any member who has never saved a profile.
The practical consequence is that a greeter or onboarding agent can only see people who are ALREADY seated in a channel, which is backwards: the people who most need greeting are exactly the ones not yet in a room.
Observed on day one of a 14-member self-hosted community: three members sat in the community with zero channel memberships and were invisible to our greeter agent. They were only found by a human reading Postgres directly.
Proposed solution
Add buzz community members, ideally with a filter for members who are in no channel. Alternatively (or additionally), make buzz users get --name perform the substring match its help text already promises.
Alternatives considered
We built a workaround, and the details may be useful whether or not the feature ships. Our agent bypassed the CLI and queried the relay directly over an authenticated websocket, using kind 0 for every profile the relay knows, kind 39002 for per-channel membership, and kind 9035 to drop retired identities. Diffing those yields community members seated in no channel.
Two things were non-obvious. First, auth: a plain NIP-42 handshake is rejected with restricted: not a relay member. The kind 22242 challenge response must carry BUZZ_AUTH_TAG as an additional tag, the same owner attestation the CLI injects into everything it signs. We could not find this documented anywhere, and it was the whole unlock. Second, telling agents from humans: a managed-agent kind 0 carries an auth tag and a human profile does not, which is useful for bucketing them rather than silently dropping them (this relay also carries around 30 Bumble/Honey/Fizz demo profiles).
This reconciles exactly to the 14 members shown in our Members UI: 9 humans with profiles, 4 seated with no profile, plus the agent itself.
Additional context
One gap the workaround cannot close: a member who never saved a profile publishes no kind 0 and is invisible to any agent unless already in a channel. Four of our fourteen are in that state right now. The Members UI still sees them, so the relay clearly knows about them.
Environment: self-hosted via deploy/compose, ghcr.io/block/buzz:main, Ubuntu 24.04 behind Caddy with auto-TLS.
Searched open issues and PRs for roster, "community members", "member list", BUZZ_AUTH_TAG and 22242 before opening. Closest related but not duplicates: #3156 (roster truncation above 1000 members, kind 39002) and #3204 (mention picker lists locally-managed agents instead of channel members).
Motivation
Agents in Buzz are members, but there is no supported way for one to ask "who is in this community?" A human owner sees the full roster in the Members/Invites UI. An agent has no equivalent:
buzz communityhas nomemberssubcommand, andbuzz users get --nameis exact-match only (its help text describes a substring search).buzz users get --pubkey <hex>returns[]for any member who has never saved a profile.The practical consequence is that a greeter or onboarding agent can only see people who are ALREADY seated in a channel, which is backwards: the people who most need greeting are exactly the ones not yet in a room.
Observed on day one of a 14-member self-hosted community: three members sat in the community with zero channel memberships and were invisible to our greeter agent. They were only found by a human reading Postgres directly.
Proposed solution
Add
buzz community members, ideally with a filter for members who are in no channel. Alternatively (or additionally), makebuzz users get --nameperform the substring match its help text already promises.Alternatives considered
We built a workaround, and the details may be useful whether or not the feature ships. Our agent bypassed the CLI and queried the relay directly over an authenticated websocket, using kind 0 for every profile the relay knows, kind 39002 for per-channel membership, and kind 9035 to drop retired identities. Diffing those yields community members seated in no channel.
Two things were non-obvious. First, auth: a plain NIP-42 handshake is rejected with
restricted: not a relay member. The kind 22242 challenge response must carryBUZZ_AUTH_TAGas an additional tag, the same owner attestation the CLI injects into everything it signs. We could not find this documented anywhere, and it was the whole unlock. Second, telling agents from humans: a managed-agent kind 0 carries anauthtag and a human profile does not, which is useful for bucketing them rather than silently dropping them (this relay also carries around 30 Bumble/Honey/Fizz demo profiles).This reconciles exactly to the 14 members shown in our Members UI: 9 humans with profiles, 4 seated with no profile, plus the agent itself.
Additional context
One gap the workaround cannot close: a member who never saved a profile publishes no kind 0 and is invisible to any agent unless already in a channel. Four of our fourteen are in that state right now. The Members UI still sees them, so the relay clearly knows about them.
Environment: self-hosted via
deploy/compose, ghcr.io/block/buzz:main, Ubuntu 24.04 behind Caddy with auto-TLS.Searched open issues and PRs for roster, "community members", "member list", BUZZ_AUTH_TAG and 22242 before opening. Closest related but not duplicates: #3156 (roster truncation above 1000 members, kind 39002) and #3204 (mention picker lists locally-managed agents instead of channel members).