Summary
buzz channels members --channel <uuid> returns only pubkey and role:
[{"pubkey":"<hex>","role":"owner"},{"pubkey":"<hex>","role":"bot"}, ...]There is no display_name. Since mention resolution keys off display names of channel members (crates/buzz-relay/src/workflow_sink.rs pairs get_members with get_users_bulk precisely to obtain them), any tooling that needs to reason about names in a channel has to issue an N+1 lookup through users get per member.
Impact
The relay already joins membership to display_name internally for mention routing. Callers cannot see the same view.
Concretely: I wrote a maintenance script to detect and remove duplicate-display-name members from channels, matching names against the channels members payload. It reported "0 orphans" on a deployment that had 22 orphan memberships across 6 channels, because the field it was matching on does not exist. The script was a silent no-op, which is worse than not having one — it reads as confirmation that nothing is wrong.
Anything auditing "who is in this channel and what are they called" hits the same wall.
Suggested fix
Include display_name (nullable) on each member record returned by channels members. The relay already has it in get_users_bulk for this exact set of pubkeys, so this is a projection change rather than a new query.
If payload size is a concern, an opt-in flag (--with-names) would work equally well for tooling.
Related
See #4303 for the duplicate-identity condition this tooling exists to clean up.
Summary
buzz channels members --channel <uuid>returns onlypubkeyandrole:[{"pubkey":"<hex>","role":"owner"},{"pubkey":"<hex>","role":"bot"}, ...]There is no
display_name. Since mention resolution keys off display names of channel members (crates/buzz-relay/src/workflow_sink.rspairsget_memberswithget_users_bulkprecisely to obtain them), any tooling that needs to reason about names in a channel has to issue an N+1 lookup throughusers getper member.Impact
The relay already joins membership to
display_nameinternally for mention routing. Callers cannot see the same view.Concretely: I wrote a maintenance script to detect and remove duplicate-display-name members from channels, matching names against the
channels memberspayload. It reported "0 orphans" on a deployment that had 22 orphan memberships across 6 channels, because the field it was matching on does not exist. The script was a silent no-op, which is worse than not having one — it reads as confirmation that nothing is wrong.Anything auditing "who is in this channel and what are they called" hits the same wall.
Suggested fix
Include
display_name(nullable) on each member record returned bychannels members. The relay already has it inget_users_bulkfor this exact set of pubkeys, so this is a projection change rather than a new query.If payload size is a concern, an opt-in flag (
--with-names) would work equally well for tooling.Related
See #4303 for the duplicate-identity condition this tooling exists to clean up.