[rileycrane]

The Bestie tab lists the private channels you share with Bestie. From the tab you can add Bestie to one channel or to all your private channels, and remove it from any of them.

Why only private channels: agents can already read public channels, so only private channels need Bestie added.

What changes

• Private channels Bestie can read: each channel is listed with Remove.
• Add to a channel (Choose…): a picker of your private channels that don't have Bestie yet, most recently active first.
• Add to all my private channels: adds Bestie to every private channel you're in that doesn't have it.
• Adds and removes are the same NIP-29 membership events the Members dialog sends (kinds 9000/9001). After each one, the tab reads the roster again to confirm.
• Each action has its own row, so in a narrow panel its button wraps under the label.
• Also add Bestie to private channels I create is not built yet. It needs a small record of which channels the switch added, and is left for a follow-up.

Try it (just dev, with a local Bestie and two private channels it isn't in)

1. Open the Bestie tab. Under Private channels Bestie can read, click Add to a channel → Choose… and pick one channel. That channel appears in the list, and its timeline shows that you added Bestie.
2. Click Add to all. The other channel is added too.
3. Click Remove on one channel. It leaves the list.

Stack: each PR is based on the one before it: #2034 Bestie tab → #2035 Remembers you → #2036 private channels (this PR) → #2037 check-ins → #2039 Former Bestie → #2041 Remove as Bestie → #2047 Choose your bestie. #2040 (recent notes in Claude Code prompts) is separate and based on main.

Overlap: #1716 also changes features/agents/service.ts and tabs.tsx. Whichever lands second will rebase onto the other.

🤖 Generated with Claude Code

buzz-review-completed

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, integrating independent Rocket (systems/lifecycle), Mantis (correctness/security/concurrency), and Groot (product/accessibility) coverage.

Two actionable findings are inline: one P2 and one P3. The existing session services retain authorization and membership-readback ownership; the extracted sidebar comparison preserves its previous ordering.

Reviewed head f68837125121e8dfb1360086b40cc7b8fdf5d1dd against base/merge-base a5d42ffbdbd31fdc563ee7c5a245261868cf3e20. Reviewed the six-file patch, relevant callers/lifecycle, public description (no attached images), and commit messages. No concrete public-material disclosure found.

Source-only: no PR code, tests, builds, apps, or live relay operations were executed. The one hosted-check snapshot reports CI required successful; Windows validation was skipped. That does not establish the membership UI, keyboard/screen-reader behavior, narrow-layout rendering, performance, or human acceptance; those remain unverified. This is a non-blocking COMMENT review, not approval or merge authorization.

[wesbillman]

🤖 [P2] Distinguish an unread roster from an empty membership list

This empty state depends only on joined.length, although useChannelList also returns status, error, and coverage. On a failed initial discovery the store retains an empty list with status: "error" (features/relay/store.ts:1640–1650), so opening this tab says “Not in any of your private channels yet” even if Bestie already has access. No read error or roster retry appears in this section. Retained partial results can likewise be offered as “Add to all my private channels” without disclosing that only part of the roster is known.

Render loading/read-error state separately, provide the existing session.channels.refreshList() recovery, and gate or explicitly qualify bulk selection while coverage is partial. Preserve usable known rows without presenting missing rows as proof of no membership. This follows DESIGN.md’s rule against treating loading/error as an empty collection; cover failed discovery and partial-roster recovery in the component tests.

[wesbillman]

🤖 [P3] Preserve keyboard focus when the completed action removes its control

A keyboard-activated Remove stays focusable while loading, but the confirmed roster update removes this entire row from joined. Similarly, adding the last eligible channel makes addable.length zero and unmounts both Choose… and Add to all (lines 164–210), including whichever trigger received focus after the menu/confirmation closed. There is no completion handoff to a surviving control, so the user loses their focus position in this section. Shared popup return-focus behavior cannot retain a trigger that is subsequently removed. This conflicts with DESIGN.md’s focus-restoration guidance.

When an action removes the focused control, hand focus to the next suitable row or a stable section target, without moving it if the user has already navigated elsewhere. Cover confirmed removal and last-channel addition with a roster-updating fixture; the current static-list tests never unmount these controls. This is a source finding; browser focus behavior was not exercised.