[matt2e]

Summary

A community can now pick a welcome channel. Messages opens it first for new members, who see a welcome card with a title and a Markdown message pinned above its composer until they dismiss it. Owners and admins pick the channel, write the title and message, and choose the other starter channels new members join, all under Settings → Community admin → Welcome. The relay decides everything: it designates the channel, enrolls new members and validates the title and message. The client reads relay-signed state and sends narrow admin commands.

This is a draft. Tests are written but have not been run locally. The feature has only been exercised in the browser dev host against a local relay on the companion branch, for the demo recordings. See Validation status.

Companion block/buzz PR: block/buzz#9108 (relay branch primary-welcome-channel).

What it does

• Which channel opens. When no channel was explicitly requested and nothing is saved, Messages now opens the community's welcome channel, if the viewer is in it, before the existing fallbacks. The order is:

  1. an explicit request (deep link, notification, buzz://channel/…, the empty route)
  2. the saved selection
  3. the welcome channel (new)
  4. the first auto_join channel
  5. the first non-Solo channel

  Steps 4 and 5 wait while any listed channel's metadata is pending, since that channel could be the welcome channel. If one of them opens while no welcome channel is listed, the choice is provisional for the opening window (see Round 3). The choice is saved as the selection, so the welcome channel opens once per device, not on every launch. Someone who has left the welcome channel falls through to the next step. The client never joins anyone to it.

• Welcome card, pinned above the composer (5cc1261b7, replacing the card at the start of the history). In a busy community a card at the start of the history sat hundreds of messages up, so it is now pinned over the end of the welcome channel's history, directly above the composer, in the slot a preview's ChannelJoinNotice uses. Like the notice, it reports its height so --channel-preview-inset grows the history's end and the last messages scroll clear. A long message scrolls within the card, and the scroller becomes keyboard focusable only when it overflows. It is a region named by its title: the custom title, or the default ("Welcome to {community}" only for a configured name, else "Welcome"). The message renders through WelcomeMessage as before, with links, chips and the conversation's renderers. It never takes focus on mount. Dismiss hides it and hands focus to the composer if focus was in the card. An empty welcome channel shows the card and its usual "No messages yet.". ChannelBody no longer passes start, and the timeline's start slot (the start prop, atStart, the .edge[data-start] rule and the ungated edge-delta block in measure()) is restored to main's content (7c1cb2429). The card sits above the "X is typing" lane: the pinned slot's block-end padding is space-3 plus the pill's lane (space-half + 2 × space-1 + a caption line), reasoned from the CSS and included in the reported height; it keeps floating-surface with --floating-inset set beside its padding (ab7327b23). The card shows only while all four of these hold:

  1. The open channel is the welcome channel (relay-signed 39000 ["landing"], a stream), and the viewer is a member with its composer.
  2. This device has a first-open time T for the community. It is written the first time Messages opens the community, and on existing installs the first time after the upgrade. It lives in view state scoped by the community origin alone, with no viewer, under welcome-first-open, and is never replaced.
  3. The relay has no event by the viewer from before T − 600 s. One snapshot read (the session reader, then the signed HTTP POST /query bridge on both hosts) sends exactly {"authors": [viewer], "until": T - 600, "limit": 1}, with no kinds and no #h. The answer is cached per origin and viewer under welcome-earlier-activity, so a second identity on the device asks for itself. The session reader and the browser broker admit exactly this shape and no other filter without kinds or IDs (e3e15cdfc), and only about the viewer: the reader requires the author to be the transport's viewer and the broker its own identity's pubkey (ab7327b23). A kept answer is read during render, so a cached card is in the first commit with the channel; the read runs only without an answer and never retries within a mount. The native host forwards /query bodies unchanged, so it needs no new route.
  4. The card has not been dismissed on this device: welcome-dismissed:<channel id>, scoped by origin alone. An admin's later title or message edit never brings it back; moving the welcome to another channel is a new welcome, which can show once more there to a member this device classes as new (product decision; documented in channels.md, buzz-help.md and the moderation README). Leaving or removing the community forgets T and the dismissals with the rest of its device state: purgeCommunityDeviceState now clears the origin's welcome- keys (clearViewScope takes a key prefix), which the origin:viewer purge never reached.

  Nothing shows while the read is pending. A failed read (refused, error, timeout, offline, no session) shows nothing, caches nothing, and is asked again on the next visit, so existing members are never shown the card because of a network failure. These trade-offs are accepted: lurkers with no events see it again on each new device, dismissal is per device, and lurkers already in an adopted welcome channel such as #general see it once per device after the upgrade.

  ⚠️ Relay dependency. A released relay refuses this filter: p_gated_filters_authorized (crates/buzz-relay/src/handlers/req.rs) treats a filter without kinds as able to match p-gated kinds and admits it only with #p=[self], so POST /query answers 403 (api/bridge.rs) and a WebSocket REQ is CLOSED restricted:, every read fails and the card stays hidden. The companion branch now exempts reads whose authors are only the authenticated pubkey: block/buzz 7f6bca943 ("admit authors=[self] reads past the #p gate"), in WIP feat(relay): community landing channel and welcome message buzz#9108. The card needs a relay with that change; the client's gate matches it by binding the read to the viewer.

• Markdown message (round two). The message is Markdown source, rendered through the shared MessageMarkdown (GFM, soft line breaks, no HTML) in both the timeline card (ChannelBody, through useConversation() as ChannelDescription does) and the Settings preview. buzz:// channel and message links open in place; an admin pastes them from a channel's Copy link. [@Name](nostr:npub…) identity links are display-only profile chips: they open the profile from the timeline but notify nobody, and the preview shows the same chip inert. That inert chip is opt-in through a new MessageMarkdown prop, inertProfileChips, which only WelcomeMessage passes; other non-interactive callers keep showing the locator as before. Round three replaced the round-two textarea with the composer's editor; see Round 3.

• Opening and recovery states. While the channel list or its metadata is still loading, Messages shows Opening your channels… instead of the blank selection view. An empty list keeps that state for up to 10 s, once per community visit, because enrollment can finish after the list answers. A channel that arrives meanwhile opens at once. After the wait, an empty state offers Try again. It moves focus to the history pane, re-reads the channel list with a strong read (it does not reconnect a healthy session) and waits again.

• Settings → Community admin → Welcome. Shown to owners and admins (from the relay-signed 13534 roster) on any relay. The former NIP-11 gate on the card is gone (welcome.ts deleted): on a relay without buzz-landing-channel the card says so and shows only the starter list.

  • Each time it opens, it reads the designation from a fresh NIP-11 document, then reads the title and message with a strong 39000 read.
  • Welcome channel picker: public, unarchived stream channels, merged from the directory and the viewer's joined list, each with its # icon (channelIcon with ChoiceRow leading; Combobox.Control leading for the chosen value). If no channel is designated yet, the field starts empty and Save stays disabled until one is chosen.
  • Title (round two): pre-filled with the custom title or the default. 1–120 Unicode scalar values on one line: no control characters and no U+2028/U+2029. Because the default depends on who is looking, it is never inferred from the text: an untouched title resends what is published, an edited title is sent as written, and only Restore defaults sends "".
  • Message: starts with the custom text or the default. It checks the relay's rules as the admin types: 1–4,000 Unicode scalar values, and no control characters other than newline and tab. CRLF is normalized, and the text is trimmed using Unicode White_Space, which matches the relay's str::trim. Text equal to the default is saved as "use the default" (welcome="").
  • A live preview renders the same WelcomeCard from the draft, with its links inert.
  • Restore defaults resets the title and message in the draft, Cancel resets the draft to the published state, and Save publishes the full state. If the relay refuses with invalid:, its reason is shown and the draft is kept.

• Also add new members to (round two, reshaped in round three). Below the form, the starter list shows the welcome channel as a fixed first row, "Welcome channel · always joined", with its own auto_join flag left untouched, followed by only the channels whose auto_join flag is on, each with Remove. Add a channel searches the remaining open, unarchived stream channels (directory rows merged with the joined list). Each add or remove publishes auto-join-on/auto-join-off through the existing lifecycle.run at once; one change runs at a time, and Save waits for it. A joined channel's row follows the roster; for a channel the viewer has not joined, the card keeps the confirmed state itself until the directory row agrees. Errors show per row (relay refusal, or "Saved, but not confirmed yet. Try again to check."). The copy explains that adding a channel affects people who join later, and in open communities also returning people who were never in it. This replaces the per-channel "Starter channel for new members" switch in Channel settings, which is removed along with the channels plugin's adminAccess/membership plumbing; the Archive and Make private warnings now point to Settings → Community admin → Welcome.

• Relaxed flaggable(). The lifecycle owner no longer requires the viewer to have joined a channel before flagging it, so admins can toggle starter channels they aren't in. The readback feeds discovery only for channels the viewer can access (canAccess), so the Settings card holds the confirmed state for the others.

• Check again for unconfirmed saves. If the strong reread never shows a published save, the form keeps the draft, disables Save and offers Check again. It does not invite a blind republish. Check again re-reads NIP-11 and the strong 39000 while the form stays visible and the button stays focused and busy. If the change did land, the form shows the "Welcome saved" toast and returns focus to the message field. If it didn't, Save reopens.

• Host validators. The browser dev broker (channel-lifecycle-protocol.ts, shared with the TS native path) and the Rust validator (src-tauri/src/relay/channel_writes.rs) accept only the exact four-tag welcome command on the channel-lifecycle route (the three-tag form from round one is no longer admitted). Other values, extra tags, other routes and altered or foreign signatures are rejected. Native users need a rebuilt desktop binary; updating the frontend alone does not update the Rust validator.

Round 3

The six commits after ebaeae8 (2a540c7dc, 1be8f076e, 97fff3051, 6d45e0f35, de4f2ff9c, f8f8275c5):

• Starter channels scale to large communities. The starter list no longer shows a switch for every channel. It lists only the welcome channel (fixed, always joined) and the channels already flagged auto_join, each with a per-row Remove. An Add a channel search covers the remaining public channels. A channel being added is listed as "Adding…" while the relay confirms it, and a removed one stays, busy, until the relay confirms. One change runs at a time, Save waits for it, and a refusal shows beside the row (removal) or on the search (addition). Both pickers, Welcome channel and Add a channel, cap browsing with an empty query at the first 50 channels by name and end with "Showing the first 50 channels. Type a name to find more." A search still ranks every channel, so the pane holds up for communities with thousands of channels. The empty line now reads "No other channels added yet" (or "No channels added yet" with no welcome channel), so it no longer suggests the community has no channels.

• The welcome message uses the composer's rich text editor. The new WelcomeMessageEditor (src/bundled/moderation/WelcomeMessageEditor.tsx) puts EditableInput together with ComposerFormattingTools (toolbar and shortcuts) and ComposerLinkDialog, and serializes to Markdown with composerMarkdown, so toolbar or typed formatting is written as the composer sends it. Pasted channel, message and identity links show as chips. Enter adds a line break, and there are no mentions, attachments, GIFs or cards. The live preview, character count, validation, Restore defaults, Cancel and Check again work as before. In 2a540c7dc no shared composer files changed. Since 97fff3051, EditableInput has one opt-in hook, pastedText (see the npub paste below).

  • Known limitation: published Markdown reopens as its source text, as when you edit a sent message. It round-trips unchanged, and formatting one word changes only that word.
  • Follow-up: @ and # autocomplete in the editor. Plain #name/@Name references and :shortcode: emoji are not chips in the editor, so the preview can show a reference that the editor leaves as plain text.

• Announcements and lint. Adding or removing a starter channel shows an Added #name / Removed #name success toast, the same ToastNotice Save uses, which Sonner announces politely; the next change clears it. "Loading channels…" and the empty line are status regions again. Biome passes for the moderation plugin (biome check --error-on-warnings src/bundled/moderation on 1be8f076e), and the help guide mentions the 50-channel browse limit.

• The welcome channel opens on a fresh load (97fff3051, 6d45e0f35). Before this, a welcome channel whose 39000 arrived after an auto_join channel's could lose to the fallback, and the starter channel opened and stayed. Two changes fix that:

  • The starter and first-channel fallbacks now wait while any listed channel's metadata is pending, because that channel could be the welcome channel.
  • A new member's membership hints can confirm their starter channel on one read and their welcome channel on a later one. So a starter or first channel chosen while no welcome channel is listed is provisional. A welcome channel that arrives within the 10 s opening window (ENROLLMENT_WAIT_MS from the list first loading) replaces it. It reopens in place, as a replace that keeps the visit's focus, so there is no Back entry to the fallback. The fallback stays if the reader has acted first: any click or key press in the window (in the workspace only, before de4f2ff9c), or any other visit. After the window nothing changes.

  The metadata wait stays because Messages cannot see NIP-11's landing_channel: RelaySession (FOUNDATION) does not project it. docs/channels.md describes the rule.

• The welcome channel picker keeps its browse cap with a channel selected (97fff3051). Until something is typed, a Base UI Combobox showing the selected name lists items instead of filteredItems, so the picker could list every channel. The cap is now also set as the Combobox limit (50).

• A pasted npub becomes a profile chip (97fff3051, 6d45e0f35). Pasting npub1… (bare, as Copy npub writes it) or nostr:npub1… into the welcome editor inserts a display-only [@Name](nostr:npub1…) identity link. The name comes from the profile directory, or a shortened npub when the name is unknown. Like every identity link in the welcome, it notifies no one. The npub stays as pasted when it lands inside a Markdown code span or link, in toolbar code, or right after a [label]( still being typed. Typing [@Alice](, pasting nostr:npub1… and typing ) gives one valid link. This uses the new opt-in pastedText hook on EditableInput, which receives the pasted text and where it lands (draft-text offsets and the source). The hook is skipped for raw pastes and code blocks, and when the caret's marks include code or a link. WelcomeMessageEditor is its only caller; the message composer does not pass it, so the composer's paste behaviour does not change.

• The Settings preview draws channel links as the card does (97fff3051). The preview now renders through the conversation renderers, so a pasted channel link shows as the linked channel name with its icon. To supply them, the moderation plugin now also injects the conversation service (inject: ["relay", "settingsCards", "adminAccess", "conversation"]), and registration.test.ts provides it.

• The welcome switch replaces only its own visit, and the npub paste needs word boundaries (de4f2ff9c, the follow-up to the review of 6d45e0f35).

  • The provisional switch to the welcome channel replaces only the visit that chose the provisional channel, checked by history entry id as setMembersOpen does. An open Settings page, or a channel the reader has just opened from the sidebar, is never replaced. Before, the switch could close Settings, or App's departure guard could ask to discard edits, with no user action. An unrouted workspace has no visit to match, so it skips the switch while Settings is shown.
  • Any click or key press anywhere in the window settles the default. While the choice is provisional, capture-phase pointerdown and keydown listeners on document settle it; they are removed when it settles or the page unmounts. Tabbing through the sidebar or typing in a field outside Messages now counts, not only input in the workspace.
  • If focus is outside Messages (and not on the body) when the switch happens, the replace passes focus "preserve", so the welcome composer does not take it.
  • A pasted npub becomes an identity link only when whitespace or the start or end of the draft is on both sides of it, in addition to the code and link checks. This covers an unclosed backtick and completing a bare URL (https://primal.net/p/ + paste), and replaces the [label]( regex. Typing [@Alice](, pasting nostr:npub1… and typing ) still gives one valid link.
  • Tests, written but not run: confirmWelcome now ends with an act flush, and the positive case asserts the history replace right after it, so no Back entry leads to the starter channel. Negative cases also assert the history entry is untouched. New cases cover a key press outside Messages, Settings over a routed and an unrouted starter channel, focus outside Messages kept through the switch, and an npub pasted inside a code span, after an unclosed backtick, in a link label and completing a bare URL.

• A provisional welcome choice survives the host's route handoff (f8f8275c5, the follow-up to the review of de4f2ff9c). A starter channel chosen while a routed visit is still pending is resolved into that visit, and the host's handoff then passes Messages no navigation for one commit before restoring the same history entry. The render-time settle compared the choice's entry with that missing navigation and settled it, so a welcome channel confirmed later never replaced the starter channel. The settle now requires navigation to be present and to name a different entry. The switch still replaces only the provisional visit while it is shown, so Settings and later visits stay protected. A new routed positive test, written but not run, lists the starter channel while the routed visit is pending, re-renders without navigation and then with a conversation for the same entry, and asserts that the welcome channel replaces the opening with no Back entry. It was traced, not run, to fail on de4f2ff9c.

• Tests are written but not run locally, per instruction (the machine was overloaded). WelcomeSettings.test.tsx adds or changes cases for: toolbar formatting and a pasted channel link written as Markdown; published Markdown opening as source and sent back unchanged; bolding one word inside published Markdown; the list showing only starters with the welcome channel first; the 50-channel browse cap, hint and search past the cap in both pickers, including while the welcome picker shows the selected channel; adding (listed as "Adding…" while confirmed) and removing (row kept until confirmed) through the channel lifecycle, with their toasts; failed removal beside its row and failed addition on the search; starter changes held while the welcome saves; channel links in the preview; and npub pastes. Those cover a known name, a short key for an unknown name, prose, a link destination being typed, backticks and toolbar code. ChannelsPage.tabs.test.tsx adds four cases:

  • waiting for the welcome channel's metadata before opening an auto_join channel listed first
  • opening a welcome channel confirmed after the starter channel
  • keeping the starter channel once the reader clicks in it
  • keeping the starter channel when the welcome channel arrives after the window

Relay contract this depends on

Surface	Shape	Client use
NIP-11	supported_extensions includes buzz-landing-channel; landing_channel: <channel uuid>	Decides whether the welcome form (not the card) is shown, and gives the current designation for the form
Relay-signed kind 39000	Bare ["landing"] while the channel is designated; ["welcome", "<markdown>"] only while the message is custom; ["welcome_title", "<title>"] only while the title is custom; bare ["auto_join"] while a channel is a starter	Navigation precedence, the card's title and text, and the starter switches, read through the existing discovery path (the directory projection now carries autoJoin). welcome/welcome_title without landing are ignored
Kind 9002 (admin write)	content: "", exactly [["h", <channel>], ["landing", "true"], ["welcome", "<text>" or ""], ["welcome_title", "<text>" or ""]]	One full-state, idempotent save on the channel-lifecycle route, confirmed by the existing strong 39000 reread. "" means the Buzz default for that part
Kind 9002 (admin write)	[["h", <channel>], ["auto_join", "true" or "false"]]	Each starter switch, from community owners/admins whether or not they are in the channel; confirmed by the republished 39000

Limits: welcome is 1–4,000 scalar values, not blank, no control characters except \n and \t; welcome_title is 1–120 scalar values, not blank, no control characters and no U+2028/U+2029.

The relay owns enrollment: new humans are added to the welcome channel at their first entry, before the starter channels. Moving the designation never adds people who are already in the community. The relay also refuses archive, delete, make private and expiry on the current welcome channel.

Older relays. With no landing tag and no extension, navigation works as it does today (first auto_join, then first non-Solo), no card appears, and the Welcome settings card shows only the starter list. The one visible change is that the opening state now replaces the blank view while the list loads, and an empty default waits once before showing Try again.

Overlapping PRs

• PR feat(channels): starter channels: admin switch and relay auto_join flag #1624 (starter channels, merged): this builds directly on it. It reuses ChannelSummary.autoJoin, the narrow 9002 channel-lifecycle route, its strong readback, and the auto-join fallback, which now sits below the welcome channel. Its per-channel switch moves into the Welcome settings card.
• PR Let community admins set default channels #2468 (default-channel switch, open): untouched. This PR does not change the channel-details route; it changes only one sentence of copy in ChannelGeneralAccess.
• PR feat(search): browse open channels from a Channels tab in search #2164 (Channels tab in search, merged): the Welcome form's channel picker reuses its useChannelDirectory.

Decisions taken

• Wire shape: the designation, message and title live on the designated channel's relay-signed 39000, plus the NIP-11 advertisement for the admin form. There is one four-tag 9002 command. Navigation needs no extra read and no change to the FOUNDATION file relay/session.ts.
• Opening state: it covers any visit whose default list is empty, rather than detecting a fresh join, so no marker, timer owner or FOUNDATION edit was needed.
• Default text: Restore defaults followed by Save publishes "use the default" ("") for both parts rather than freezing today's copy. The default title is never inferred from an untouched or typed title.
• Markdown source, edited in the composer's editor: the welcome is stored and sent as Markdown. Round three edits it in the composer's EditableInput with its toolbar and link dialog (round two used a textarea), with a live preview. The only shared composer change is the opt-in pastedText hook, which the composer doesn't use. Identity links are display-only chips with no notification. Channels and messages are linked with buzz:// links or bare #name.
• Starter channels in one place: the per-channel switch is gone; the Welcome card's list is the only place to set them, on any relay.
• One PR: the plan's read path (PR A) and write path (PR B) are combined here.

Known design gaps

• Per-row error placement. A starter row's error is a buzz-field-error paragraph rendered after its PreferenceRow inside the SettingsGroup, as BestieTab does; the shared row has no error slot. Left as-is for this round.
• Heading levels inside the card. Markdown headings in the welcome render at the levels MessageMarkdown gives message bodies, with no offset under the card's own heading. Left as-is for this round.

Deferred

• Unsaved-changes guard for the Welcome form. Contributed Settings cards unmount when you switch sections and have no unsaved-departure hook. Only Profile has one, through App.tsx, which is FOUNDATION. In v1 a draft is dropped when you leave the section. The follow-up would pass an unsaved-change callback to cards in Settings.tsx and make the App.tsx prompt generic. It needs explicit approval because it edits a FOUNDATION file.
• Disabling protected-channel controls in the UI. Archive, Delete, Make private and expiry are not disabled for the welcome channel. The relay refuses them, and the refusal appears through the existing lifecycle error copy.
• Real-engine check of the pinned card's geometry. The card's lane above the typing pill and the history's grown end are reasoned from the CSS and covered only by jsdom tests, which cannot prove layout. Still owed, in Chromium and WebKit or the native app: a fresh profile opens the welcome channel with its card, a second identity types, and the "X is typing" pill stays visible below the card while the last message scrolls clear of it, in both themes and with enlarged text. The former start-slot scroll-anchoring journey is no longer owed: that code is restored to main (7c1cb2429). Browser cases added or removed in this PR: none.
• @/# autocomplete in the welcome editor (see Round 3).
• Custom emoji in the welcome are not rendered, and the message is still trimmed at both ends.
• Mobile. Not in scope.
• Also not in scope: a "Browse channels" action in the empty state, and a buzz-mcp flag.

Validation status

• CI is green at 49019835b (run 42244417480): JavaScript 1–6/6, Browser measurements, Browser journeys (chromium 9/9, webkit 14/14), Flake check (Vitest 2/2, chromium 8/8, webkit 8/8), Rust and tool integration (including lifecycle_accepts_only_the_exact_landing_command), Native browser fixture, Protected agents and WebKit recording (macOS), and CI required. Windows native validation was skipped by the workflow, as on earlier runs. This is the first run on this branch in which Vitest ran: every earlier run stopped at Biome in pnpm check.
• What it took (592281e5c, 49019835b; details in their messages): a Biome format fix in channel-lifecycle-protocol.ts; the browser policy-relay fixture now answers /api/join-policy with a 404, since Messages' welcome read goes through the broker's info route, which fetches the join policy after NIP-11, and the fixture asserted every bodyless GET was NIP-11 (470 of the 472 journey and measurement failures); and test fixes for the first Vitest run: stable snapshot fakes, the message editor's value set inside act, a scoped selector, Base UI's open list hiding the pane from role queries, history bounds in the ChannelsPage harness, both cards registered natively, and the purge's welcome store in the expected failures. Code changes in that commit: the moderation README keeps one "Getting started" section, and the purge names its welcome store "welcome record" in its warning.
• Local runs: WelcomeSettings.test.tsx and WelcomeCard.test.tsx (49 tests) and the ChannelsPage welcome-channel test passed on this machine; tsc --noEmit and Biome passed locally at 49019835b, and design:check at 71782fcf5; CI's pnpm check ran all three at 49019835b. Everything else ran only in CI. Commits and pushes used --no-verify, so no hook checks have run.
• FOUNDATION file touched: src/features/relay/session.ts has a one-line change in 217c1e1e5, wiring the channel store's acceptDirectory into the lifecycle capability so a confirmed starter-flag readback updates the cached directory. It needs explicit human sign-off.
• Manual use so far is limited to the demo recordings: the browser dev host against a local relay built from the companion branch, at de4f2ff9c. Not tried natively, and not tried against any other relay.
• Agent review: two rounds ran on dd2c58c and bbccebc and were addressed in bbccebc and 14b8831. The first human review round was addressed in be1258d, and its follow-up review in ebaeae8. Those two commits have not been re-reviewed. Round three's agent review ran on 2a540c7dc and was addressed in 1be8f076e. A review of 97fff3051 (npub paste in code or links, and a welcome channel that arrives later) was addressed in 6d45e0f35. The review of 6d45e0f35 (the automatic welcome switch could close Settings without warning, the switch could replace a channel the reader had just opened, and the provisional-switch tests lacked a completion barrier) was addressed in de4f2ff9c. The fail-then-pass runs that review asked for have not been done. The review of de4f2ff9c (a route handoff could cancel the welcome switch, and the routed positive case was missing) was addressed in f8f8275c5, which has not been re-reviewed.
• Demo videos: admin and join recordings at de4f2ff9c exist locally and are not attached. In the join recording a new member opened in the welcome channel, with the starter channel in the sidebar. Both channels arrived together, so the provisional switch was not exercised.

Tests added or changed (colocated):

• landing.test.ts, discovery-landing.test.ts, store.test.ts, store-discovery.test.ts: tag parsing including welcome_title, NIP-11 parsing, the text and title rules, autoJoin in the directory projection
• channel-lifecycle.test.ts, relay-broker-api.test.mjs, channel_writes.rs, native-api.test.ts: the exact four-tag command shape, confirmed, refused and unconfirmed outcomes, flagging an unjoined channel, and broker and native admission
• MessageMarkdown.test.tsx, WelcomeCard.test.tsx: Markdown rendering, the interactive identity chip, the inert chip behind inertProfileChips, the default and custom titles
• ChannelsPage.tabs.test.tsx: precedence, waiting for pending metadata, a provisional default replaced by a later welcome channel, including through a routed visit's handoff (and kept after a click, after a key press outside Messages, or after the window; never replacing Settings, routed or unrouted; focus outside Messages kept through the switch), the opening, empty and wait states, Try again, and the Markdown card with a custom title
• welcome-pin.test.tsx, device-state.test.ts, reader.test.ts, relay-broker.test.mjs: the four card conditions, a kept answer in the first commit, no retry within a mount after a failed read, dismiss in one channel then the welcome moving to another and back, the purge forgetting only the origin's welcome keys, and another author's kinds-less read refused by both gates
• WelcomeSettings.test.tsx, registration.test.ts: the form gates, title and message rules, Restore defaults and Cancel, the untouched-title rule, refusal, Check again, the starter list (fixed welcome row, only flagged rows, Remove and Add a channel, busy and error states, toasts, the unsupported relay), the 50-channel browse cap in both pickers (also with a channel selected), the message editor's Markdown round trip, npub pastes in prose, code (including after an unclosed backtick), link labels and destinations, and a bare URL being completed, channel links in the preview, and card visibility by role
• ChannelSettingsPanel.test.tsx, ChannelGeneralAccess.test.tsx, ChannelNavigationState.test.tsx: the removed switch and the new copy

Checks still to do

• CI green on the merged tree (run 42244417480 at 49019835b); of the affected test files, only the WelcomeSettings, WelcomeCard and one ChannelsPage test ran locally
• Light and dark themes for the card, the opening and empty states, and the Welcome form and starter list
• Narrow and wide widths, and 200% text
• Keyboard and pointer use of the channel picker, title field, message editor (toolbar, shortcuts, link dialog), starter Remove buttons and Add a channel search, and the action row, plus focus after Save, Check again and Try again
• Scroll anchoring when the card enters or leaves the edge, in both Chromium and WebKit (the journey described above)
• An agent exercises both flows against a local relay running the companion branch: an admin sets the welcome and a starter channel, and a new member joins through an invite and lands in the welcome channel
• An admin reopens published Markdown in the message editor and confirms it round-trips, including after formatting part of it
• The starter pickers with a community of more than 50 channels, including the welcome picker with a channel selected
• A new member whose starter channel is confirmed before their welcome channel lands in the welcome channel, a click in the starter channel first keeps them there, and Settings opened during the opening window stays open
• Pasting a copied npub into the welcome editor in prose, inside code, after an unclosed backtick, inside a link being typed and completing a bare URL; the message composer's paste is unchanged
• A native rebuild for the Rust validator change
• A human tests both flows
• The review-completed marker is not set; add it only after the steps above hold

Size

About 3,000 added and 290 removed production lines against main (including CSS and the host validators), at ab7327b23. Round two added Markdown rendering, the title, the starter list and the validators, and removed the per-channel switch and welcome.ts. Round three added about 695 and removed about 150 of those lines, for the searchable starter list, WelcomeMessageEditor, the default-open fix and its visit-scoped switch, the npub paste and pastedText hook (25 lines in EditableInput.tsx), and the preview's channel links. 97fff3051 and 6d45e0f35 together add 175 and remove 32; de4f2ff9c adds 60 and removes 31, in ChannelsPage.tsx and WelcomeMessageEditor.tsx. The pinned welcome (5cc1261b7, e3e15cdfc) and its review follow-ups (7c1cb2429, ab7327b23) net about 350 added production lines: welcome-pin.ts, the card's pin, the gate and the purge, less the timeline's start slot now restored to main. WelcomeSettings.tsx is 1,071 lines and WelcomeMessageEditor.tsx 277. Tests are about 3,695 added and 405 removed lines, and docs about 275 added and 40 removed.

🤖 Generated with Claude Code