[kiranmagic7]

Summary

buzz channels members serialized the channel membership tags directly, so each record contained only pubkey and role. This change loads member profiles with one batched kind:0 filter and adds a nullable display_name to each record while preserving membership order and roles. The profile projection uses the relay's existing name fallback; missing or malformed profiles produce null.

Related issue

Fixes #4437. No duplicate implementation was found; the closest prior CLI mention work is #3330, which does not change channels members output.

Testing

• cargo test -p buzz-cli channel_member -- --nocapture
• cargo test -p buzz-cli
• cargo clippy -p buzz-cli --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• just ci

All checks passed. No screenshots are needed for this CLI JSON change.

[chessing234]

looking at this for #4437 — if you're joining display names via users bulk on the same pubkeys from the membership event, that matches how the relay does mention routing. please keep display_name nullable when a profile is missing so tooling can tell "no name" from "not returned".

[kiranmagic7]

Thanks, that is the contract in this branch now. display_name is added as JSON null when no profile/name is available, so callers can distinguish a missing profile from a returned empty string. The regression channel_members_include_nullable_profile_display_names covers that nullable path and I will keep it unchanged.

[kiranmagic7]

The nullable display_name contract is unchanged. I merged current main into the branch, resolved the channels.rs conflict, and reran the two focused channel-member tests, all 345 buzz-cli tests, and just ci successfully on e70a995cd.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 5397ea49e27fd56d4e0346e2120906d09ac91579...ced7113861c2c5846f49525e84b127574989910b.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly
@buzz-security-review ced7113861c2c5846f49525e84b127574989910b to authorize a new review.
Any previous review applies only to its recorded range.

[kiranmagic7]

The canvas changes in #6780 just landed and rewrote channels.rs, so I rechecked the overlap against current main (b6a26556e). This branch still merges cleanly: those changes begin after cmd_list_channel_members, and the nullable display_name contract plus focused tests are untouched. The remaining blockers are review and Block-side workflow/security authorization for this exact head.

[kiranmagic7]

Current main introduced a conflict in channels.rs when #8175 added the channel-label parsing test. I merged it into this branch, preserving both that test and the nullable display-name coverage. GitHub now reports the updated head ced711386 mergeable, and DCO passes. git diff --check also passes; I could not rerun the Rust tests on this host because cargo is not installed.

[kiranmagic7]

main now includes #8234, which also changes channels.rs, so I checked the overlap. That patch only extends cmd_list_channels for OutputFormat::Agent; cmd_list_channel_members still returns the raw membership tags without display_name. This head still merges cleanly with current main, so the nullable profile enrichment remains separate.

[kiranmagic7]

Two newer changes now touch channels.rs: merged #8594 only adds auto_join to channel updates, and #8779 only adds template-list dispatch. Neither changes cmd_list_channel_members; this head still merges cleanly with current main (d342cf141), so the nullable display-name work remains separate.

[kiranmagic7]

Since the last overlap check, main has taken the credential-chain migration (#8999) and unread-state dispatch (#8789) in channels.rs. Both stay outside cmd_list_channel_members, and the current catalog/template PRs touch other functions or dispatch arms. GitHub reports this head mergeable with current main (d839d3731), so the nullable display_name change remains distinct.