[matt2e]

What

The In DM · <Bestie name> link at the top of a Bestie DM thread, such as one opened from Activity, now opens the Bestie page. The thread opens in Bestie's thread pane, and the chat history scrolls to the thread's root message with a brief highlight. Before this change the link opened Messages, which hides the promoted Bestie DM from its sidebar.

Before / after

Left: f9ce9dfc4 lands in Messages, whose sidebar lists no row for the Bestie DM; right: e6d86f54e opens the Bestie page with the thread on the right and the root message highlighted.

bestie-linkback-before-after.mp4

Cause

Every link to a DM, a thread or a message opened Messages. Nothing routed links into the promoted Bestie DM to the Bestie page.

Fix

• Handoff to Bestie. When Messages starts presenting a pending visit to the promoted Bestie DM or one of its threads, it hands the visit to the Bestie page before drawing it. The visit keeps its history entry. A thread visit opens in Bestie's thread pane under the thread placement preference. Messages hands off only its own pending visit, not a settled visit kept on screen under Settings (ChannelsPage.tsx, bestie/routes.ts).
• Root reveal. Bestie reuses Messages' message opening (useMessageOpening and the timeline's inlineTarget reveal). It reads older history until the root loads, then scrolls to the root and highlights it. The root is the one the thread pane verifies, so a buzz:// link whose thread hint names an unrelated message reveals the reply's real root, not the hint.
  • For a thread visit, the chat stays on screen and usable while Bestie looks for the root.
  • The reveal happens once, on the first presentation of a handed-off visit. It doesn't happen for Bestie's own View thread, including View thread activated again on the thread already shown, or for Back/Forward, and it stops if the reader scrolls the chat or sends from the main composer first.
  • The thread pane keeps keyboard focus.
• Single-message route. A link to a single message in the Bestie DM opens the Bestie page scrolled to that message when it is a top-level message in history. This covers notifications, ⌘K results and buzz:// links without a thread. A reply, or a message that isn't found, opens as its thread, as in Messages. Back/Forward to such a visit returns to the reply's thread or the chat, without revealing the message again. This holds even when the reader left before history answered or reloaded the app.
• Other entry points fixed by the same path: Activity's "Open in channel", notifications for thread replies, buzz:// thread permalinks, choosing the Bestie DM from a channel result in search, and Back/Forward to an older visit of the DM or its threads.
• Unchanged: other DMs and channels; Forward and Members, which have no Bestie route and stay in Messages; and a visit Messages had already opened before the promotion was known.

Shared-code changes

Each change is additive or opt-in for existing callers:

• ChannelTimeline: an onReaderIntent callback, fired only by real wheel, touch, key and pointer input on the history. Its inlineTarget.focus type widens from false to boolean. The thread pane keeps focus through the timeline's existing useMessageReveal support for marking an arrival without focusing it. This PR doesn't change useMessageReveal.
• Navigation history: the dismiss predicate also receives each visit's id. Closing a thread then retires the visits recorded for it, however they were addressed.
• Bestie provider: BestieNavigationProvider memoizes its value, so channel-list churn no longer re-renders Messages while a Bestie is promoted. useBestieConversation no longer matches a missing session when no Bestie provider is mounted.

docs/buzz-help.md, docs/navigation-history.md and src/bundled/bestie/README.md are updated.

Validation

• Vitest: 72 files, 1,744 tests, all passing. They cover Bestie, ChannelsPage, the shell, channel navigation, Inbox/Activity, the timeline, the reveal hook and navigation history. The new tests fail without the fix.
• Static checks: tsc --noEmit and biome are clean.
• Real browser: headless Chromium at 1440×900 against tests/browser/fixture.mjs, with the same seed and the same flow on both commits: Activity → the Bestie's reply → open its thread ("1 reply") → "In DM · Jitter". The run had no console errors. This produced the video above.
• No browser journeys were added or removed.

Known limits

• Not checked against a real account. Dev builds can't sign in to the production relay. It requires an organization sign-in token (requires_nip_fi) that browser-host/relay-broker.mjs doesn't send. The fix was checked on the fixture relay in real Chromium instead.
• One no-op Back stop. Reopening the Bestie place already on screen from search or a notification leaves one Back stop that does nothing. Those callers open links themselves, so there's no single place to intercept them.
• Handed-off entries stay Bestie visits. A history entry Messages handed to Bestie becomes Bestie's address. If the Bestie plugin is later disabled or the Bestie changes, Back treats that entry like Bestie's own thread visits instead of reopening it in Messages. This is documented in src/bundled/bestie/README.md.

🤖 Generated with Claude Code

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, integrating independent Rocket, Mantis and Groot coverage.

Reviewed head e72ff49de9248a0bfb723780ed9792ec5cdb2f20 against base/merge-base 3bcf1c4bb1111d924a84d9b710c1da2db80ccf0b. Two P2 navigation findings are inline: an unresolved exact reply is lost on Back, and a repeated internal View thread opening unexpectedly reveals the root in the main history. The documented no-op Back stop and continued Bestie ownership of handed-off addresses were treated as intentional constraints.

Optional description cleanup: the Shared-code changes section attributes changes to useMessageReveal, but that file is unchanged against this base; this PR reuses its existing focus/mark support and widens the timeline’s inline-target focus type.

Source-only review of the diff, callers, tests and relevant product/design/history contracts. No tests, builds, apps or browser/native workflows were run; validation claims in the PR were not independently reproduced. The linked video was not inspected, so its contents and demonstrated behavior remain unverified.

[kalvinnchau]

🤖 One navigation correctness issue remains with conflicting thread hints.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating independent Rocket, Mantis and Groot coverage.

Reviewed head 893b4e66c94689197c3c11d764d2843d001aef3d against base/merge-base 3bcf1c4bb1111d924a84d9b710c1da2db80ccf0b, focusing on the repair since e72ff49de9248a0bfb723780ed9792ec5cdb2f20. Both prior P2 findings are addressed in source; no new actionable findings in this repair delta.

Unrecorded exact-message returns now resolve their destination before applying the visit, independently of revealing the message. Repeating View thread records internal ownership before restarting the same history entry, preventing an unintended root reveal. The three added regression tests cover the prior failure cases; the README and corrected shared-hook description match the implementation. Earlier source coverage and the documented history tradeoffs remain unchanged.

Separately, kalvinnchau’s conflicting thread-hint finding remains relevant at this head. The hinted-root selection predates this repair and is unchanged here. This follow-up closes our two earlier findings; it does not resolve that separately reported issue or independently reproduce its browser results. No duplicate inline added.

Source-only: tests were read, not executed. No builds, apps, browser/native workflows or live reload/scroll-anchoring behavior were exercised; the PR’s validation claims were not independently reproduced. The linked video remains uninspected.

[tellaho]

🤖 Drip design review at 893b4e66c94689197c3c11d764d2843d001aef3d.

The intent is to open linked Bestie messages and threads where people already find that conversation.

Must-fix, already reported: a conflicting thread hint can highlight an unrelated message beside the correct thread. Reveal the verified root, or suppress the conflicting hint. The existing finding remains applicable: BestieConversation.tsx:150–152,614–625 uses the hinted root for the chat reveal independently of the thread's resolved root. No duplicate inline added.

No additional design findings. The existing chat/thread composition fits this bug fix.

Checked the source and frames from the linked wide, light-theme recording; its after-state is e6d86f54e, not this head. Not independently checked: current-head runtime, narrow layouts, dark theme, enlarged text, keyboard/screen-reader behavior, empty/loading/error recovery, long content or many-agent activity. Tests were read, not run.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, integrating Rocket, Mantis and Groot.

Reviewed the verified-root repair at 4c24a68a689911981ad690cf91b532f5f90b6215 against base/merge-base 4ea0a40490d3900570734957cca6df0945780fa4, retaining the prior feature review. One residual P2 is detailed inline: a conflicting hint can still reveal an unrelated root when that thread already has a verified open tab. The fresh-tab case is repaired, and the two previously repaired Back/View thread findings remain addressed.

Source-only: regression tests were read, not run; no builds or app execution. The PR description was inspected, but the linked video remains uninspected. Live scrolling, focus and visual behavior remain unverified.

[matt2e]

🤖 Re: Drip design review @ 893b4e6: the must-fix is resolved.

• 48317d6 ("reveal a thread visit's verified root, not its link's hint") makes the chat reveal follow the root the thread reader verifies, not the URL's threadRootId. Until the thread resolves nothing is sought, so a conflicting hint never highlights an unrelated message. It adds a test for exactly this case: a reply link whose hint names an unrelated top-level message reveals the verified root and never the hinted message.
• 4f36be04ff10 then closes a follow-on gap (r4509744434). Verification is now recorded per visit for that visit's own message, so an already-open hinted thread's earlier verification can't stand in for a new link.

At head 4f36be04ff, BestieConversation.tsx reveals only record.rootId when record.verified. CI is green.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating independent Rocket, Mantis and Groot coverage.

Reviewed head 4f36be04ff6e45d7add98237179c9fbfe2d8d96c against base/merge-base 7444eb12992a237eec786f5b81b94cdf48ff9c65, focusing on the retained-tab verification repair. The prior conflicting-hint P2 is addressed: a new reply cannot borrow an open tab’s earlier root verification. One repair-introduced P2 is inline: a fresh in-page visit to the same message already selected in a retained reader never gets its verification notification, so Bestie omits the expected chat-root reveal. Earlier Back/View thread repairs remain addressed.

Source-only: tests and relevant callers/contracts were read, not executed. No builds or apps were run, and the PR’s validation claims were not independently reproduced. The public PR description was inspected; the linked historical video remains uninspected. Live scrolling, focus and visual behavior remain unverified.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating independent Rocket, Mantis and Groot coverage.

Reviewed head 0d61905757e4622790b33191ff7bbbcad3441d05 against base/merge-base 40e6ccb597cf9d8b47f9692de8285458cc304017, focusing on the same-message retained-reader repair. The prior P2 is addressed in source; no new actionable findings in this repair or its relevant integration.

The root report now follows the settled opening’s navigation, so a fresh visit receives verification after a successful retarget even when its root and message are unchanged. Pending, failed and superseded retargets do not adopt the new opening; diversion can only re-report the prior confirmed message. The added regression covers an intervening plain Bestie visit, a fresh link to the retained message, a second root reveal and focus remaining in the thread. Earlier Back/View thread and conflicting-hint repairs remain addressed; prior feature coverage and documented history tradeoffs are retained.

Source-only: tests were read, not run; no builds or apps were executed, and the PR’s validation claims were not independently reproduced. The public PR description was inspected; the historical linked video remains uninspected. Live scrolling, focus and visual behavior remain unverified.