[TheSentinel454]

Summary

Community owners and admins can make a channel a default channel from the app: Members → General access gets a "Default channel" switch on open, unarchived stream channels. The relay then joins every new community member to it, with the channel's join role (Member or Guest).

The relay already supported this (kind:9002 ["auto_join", "true"|"false"], community owner/admin only, open and unarchived streams only — NOSTR.md § Default channels in block/buzz). Until now it was only reachable from the relay CLI.

How it works

• Separate, narrow command. The default-channel setting is sent on its own as ["h", <channel>] + ["auto_join", ...], never combined with a details save. A community admin is not necessarily a channel admin, and the details editor always resends name/about, which needs channel admin. Both the TS broker validator and the native Rust validator admit exactly that two-tag shape for route channel-details and reject it combined with anything else.
• Role comes from the relay. The switch shows only for community owners/admins per the relay-signed kind:13534 roster (useCommunityRole), and the write re-reads the channel before sending.
• Confirmed, not optimistic. The switch changes only after the relay's kind:39000 readback shows the bare ["auto_join"] tag in the new state. An accepted write that does not read back stays in the existing uncertain state and cannot be resubmitted until refreshed.
• Join role (General access: who can post) already existed in this dialog; the switch sits next to it.

What got simpler

Nothing removed. The change reuses the existing General access flow, details protocol and readback confirmation rather than adding a second write path or store.

Tests

• channel-details.test.ts: the narrow command's exact tag shape, validator rejection of combined or malformed commands, authorization by community role rather than channel role, and readback confirmation (including a private channel whose readback carries no default-channel state).
• ChannelGeneralAccess.test.tsx: switch visibility by community role and channel eligibility, toggling on and off through the real flow, and the unconfirmed path.
• channel_writes.rs: details_admit_only_the_exact_default_channel_command.

Gated on a Blox workstation: biome, icon check, rustfmt, check-push.mjs (types + related unit tests, design system, clippy), focused Vitest, and cargo test relay::channel_writes.

🤖 Generated with Claude Code

[kazemek21]

Kyle reviewed the PR and the Nexus review-tracker notes and approved with the two non-blocking suggestions below.

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[kazemek21]

[P2] Preserve default-channel management for community admins with read-only access

Should this control remain available when a community admin is a channel Guest or nonmember? discovery.get() marks Guests/previews read-only, so the early return hides it; nonmembers also fail lifecycleSettings(). The relay accepts this command based on community role without requiring channel membership. Please separate that management path from channel posting/edit rights.

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[kazemek21]

[P2] Confirm only the default state for a default-only command

If another admin renames the channel between the last authorization read and confirmation, the toggle can succeed but this comparison leaves it permanently unconfirmed. check() repeats the old name comparison and attempts.has(id) prevents another save. Should the defaultChange branch confirm only the requested autoJoin state, while retaining the existing full-details checks for ordinary saves?

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[wpfleger96]

🤖 Automated review of head 3b74e39ed5f9d31bcda94dad059ddafe68cb12a8.

IMPORTANT: main already ships this feature. #1624 (merged 2026-11-05, 84224a52c7) added a "Starter channel for new members" switch to ChannelSettingsPanel.tsx, shown only to community owners and admins (managesCommunity(role)) on active public stream channels. It sends the same two-tag kind 9002 [["h", id], ["auto_join", "true"|"false"]] through the lifecycle route (auto-join-on / auto-join-off in channel-lifecycle-protocol.ts), and both host validators already admit that shape (validateLifecycleTemplate and channel_writes.rs lifecycle). It also confirms from the republished 39000 and parses the bare auto_join tag into ChannelSummary.autoJoin.

This PR adds a second control for the same relay setting in Members → General access and a second admission path for the identical command on the channel-details route (defaultTemplate in channel-details-protocol.ts, the early return in details() in channel_writes.rs). Rebased onto main as-is, admins would see two switches for one setting with different names ("Default channel" and "Starter channel for new members") and different save, confirmation and error paths, and the docs would describe the same setting twice under two names. It is also why the PR conflicts with main in ChannelGeneralAccess.tsx, which now warns about starter channels when one is made private.

Fix: close this PR in favor of #1624. Or, if something here should survive, rebase onto main and keep only that change on top of the existing lifecycle command and ChannelSummary.autoJoin, without the parallel channel-details path. The one difference I found is the join-role wording ("join automatically as guests/members").

Smaller note on the same flow (only matters if any of this survives): a community admin who is not a member of the channel gets the read-only preview in the members dialog, so they never see the switch here, even though the relay lets them set it without membership.

[morgmart]

🤖 Design review (critical path: new-member onboarding)

Looks good from a design standpoint. No must-fix items.

Optional:

• After switching Default channel, the status reads "Access updated". "Default channel updated" would match what the person just did; the saving message already says "Saving default channel…".
• The switch says new members join "as guests", but the access menu right above calls that "View only". Using the same words ("join and can only view") avoids a second name for the same thing.
• Making a default channel private or archiving it hides the switch but keeps the setting, so reopening the channel silently makes it a default again. Consider clearing it on those changes, or saying so where the admin makes them.
• The "Couldn't check your community role" error can show to channel admins who aren't community admins and would never get the switch. Showing it only when the person might be a manager would avoid a confusing alert.

Not checked: no screenshots in the PR and I didn't run the app, so I haven't seen the row in light/dark, narrow windows, or enlarged text, or what a new member sees on first join.

[tellaho]

🤖 Please use View only for the guest case, matching the General access menu (generalAccessOptions["view-only"].label). For example: "New community members join automatically with View only access." Calling the same access mode "guests" here makes it sound like a different setting.

[tellaho]

🤖 Please keep this warning and Retry action hidden for channel admins who are not community owners/admins. !community.manager && community.readError also matches a failed roster lookup for those users, even though they would never be offered the Default channel switch. They should not see an alert about a setting they cannot use when their channel access is unaffected. Please scope the role-check recovery to users for whom this control is relevant, and add regression coverage for a channel admin who is only a community member when the role lookup fails.