Use relay sidebar API for unread and read-state authority

[tlongwell-block]

Make the relay the one authority for unread and read state

Problem

Today the app decides what is unread on its own. It counts from the messages it happens to have loaded, keeps its own read positions, and syncs them through its own encrypted read-state events. Two sessions of the same person can disagree, a channel that was never opened has no trustworthy count, and every client has to reimplement the same rules.

Outcome

The relay's /buzz/v1 sidebar API (block/buzz#7906) answers "what is unread for this person" and stores how far they have read. The app renders that answer and sends reading intent. It no longer counts.

• One answer on every device and session: counts come only from relay responses.
• A count is exact, at_least, or unknown. Unknown is never drawn as zero.
• Reading is saved to a local journal first and delivered when the relay is reachable, so a closed window or a lost acknowledgement does not lose it.
• The relay also decides which replies count. Count unread replies only in conversations you are part of #471 put that rule in the client on main (a reply counts when it is in your conversation, mentions you, is in a DM, or is a broadcast). The rule is kept, and the relay now applies it and says why each unread reply counts. The client-side conversation lookups Count unread replies only in conversations you are part of #471 added are removed by this merge, not kept beside the relay's answer.
• The Inbox page and its Drafts view, which landed on main while this branch was open (Show exact Inbox conversations with read recovery #499, Resume scoped drafts in Inbox and discard deleted attachments #502), are kept. The Inbox now takes its rows from the relay's answer too. See "Inbox" below.
• The app's own counting, read-state codec and visit tracking are deleted, not kept as a fallback.

The contracts are docs/unread.md and docs/inbox.md. Read those before the code.

Before this merges: three things that change who has unread

• Needs feat(relay): private read-state accessory API buzz#7906 at a09bbdff5 or later. This client expects each unread message to carry reason. Earlier heads of #7906 sent attention instead, and this client does not decode that. #7906 is now at ce9481aa6, which is what the live pass below ran against. The two commits after a09bbdff5 do not change the wire format: one lets a thread whose root is not a counted kind (a diff, for example) be read, and one adapts the API's auth to main's NIP-FI Shadow mode. #7906 can merge first. It has no caller until this PR.
• Deploy order. The relay with #7906 must be live with BUZZ_V1_ENABLED=true first. Against a relay without it, unread is unsupported and nothing is badged. There is no legacy fallback, by design.
• The packaged desktop app has no adapter for this API yet. On main the desktop shell syncs read state through native code. This PR removes that path, and only the web transport calls the new API. Until a native adapter lands, a desktop build from this branch has no synced unread. That adapter is the first follow-up. Desktop previews build from main on a schedule, so a preview built after this merge should not be promoted to the updater feed until the adapter lands.

What changes for a person using Buzz

These are deliberate. Each differs from main today.

1. Reading moves a position, not a set of receipts. After a message has been fully visible for the dwell time, the app marks that timeline or thread read through its newest such message. Everything earlier in the same timeline or thread becomes read with it. That includes earlier top-level mentions and broadcasts in a channel, which main keeps unread one by one.
2. Main's "catch up at the bottom" rule (Fix unread catch-up and reading focus #470) is removed. The position in 1 replaces it. Fix unread catch-up and reading focus #470's reading surfaces (focused panel, tab, composer) and its dwell time are kept as main has them.
3. "Mark as Read" on a channel reads through the relay's latest message for that channel, not through the click time. A message that arrives after the relay's answer stays unread.
4. A badge clears as soon as you read, before the relay confirms and while offline. The relay's count is kept unchanged underneath. If the local save fails, or the relay answers blocked or invalid, the badge comes back.
5. "Mark unread" is local to this browser profile and is not synced. On a message it marks only that message. It strengthens the channel label, adds no attention dot, and leaves the relay's count as it is.
6. Someone else's read activity alone never makes a channel unread or moves it in Recent.
7. If you lose access to any channel while a read action is still being saved, the actions not yet saved fail with an error and can be repeated. Main kept them. Nothing is lost silently. This is tested and written into docs/unread.md.
8. A broadcast reply can change its reason after the fact. When the relay cannot decide in time whether a broadcast reply is in your conversation, it stays unread as a broadcast, which has no notification category. A later refresh can upgrade it to a conversation reply.
9. Read positions and Mark-unread reminders from earlier preview builds start over once. Nothing is imported from the old local database (buzz-read-state-v1). It is left in the browser profile, never read again, and this client carries no code for it.

Inbox: main's page, answered by the relay

Main gained an Inbox while this branch was open: first a data layer, then the page (#499), then Drafts (#502). Main's Inbox decides on the client which messages need attention, which is the thing this PR removes. The merge keeps main's page, finite feed and types and rebinds the rows to the relay: a row exists only for a message the relay currently calls unread with reason direct, mention or conversation. The contract is docs/inbox.md.

What a person sees that differs from main's Inbox

1. The Inbox is unread only. A conversation leaves the list when it is read. Main kept read conversations as an archive.
2. Two controls are visible and do nothing. "Unread only" changes nothing, because the list is already unread only. "Mark unread" in the row menu is always disabled, because every row is unread. Both are left as main has them, untouched, until the relay can list what needs attention (the follow-up below). Hiding them is a product call that is open with Tyler.
3. An opened conversation stays open after it is read. Opening a row captures that visit. The conversation stays in the detail pane until Back or Close, even though its row has left the list. It adds no row. Loss of access and a deleted message are shown by the existing detail and readers.
4. Back lands on the first remaining row after a read visit, because the row that was opened is gone. Main returns to the row it came from.
5. Clicking a top-level channel mention opens it and reads nothing at that moment. Reading it means reading the channel through that point, which also reads everything before it, and a click must not do that silently. It clears the way any channel message does: once it has been shown, focused and settled for the dwell time, the reader marks the channel read through it, older top-level unread included. Thread rows read their thread on open. DM rows read the DM.
6. A manual "Mark unread" alone makes no row. It overlays a row the relay admits, and it is not erased when its row is absent.
7. A mention sent before you joined gets a row after you join, if the relay calls it unread. Before joining, cached public messages ask nothing and show nothing.
8. Unread from before launch may have no row. Rows come from messages the session already holds, plus the finite feed of messages addressed to you by tag. A DM that arrived before the app started was measured this way on the browser fixture: the relay reports it unread, the sidebar badges it, and the Inbox says "No recent activity". When a later DM arrives the row appears and counts only the messages it holds (1 where the relay says 2). Main kept a dedicated unread store for this. The relay listing follow-up removes the gap.

Kinds and horizon come from the relay: it advertises the kinds it answers for (today 9, 40002, 45001, 45003) and applies its own 30-day window. A row's messageId and rootId describe one message, the oldest unread one in the group. latestMessageId, the target and readThrough follow the newest.

What changed in main's page to fit

InboxPage.tsx changes by +12 / -11 lines against main: the selection holds the clicked item, and the effect that closed the detail when its row left the list is removed. Nothing else in the page, the detail or Drafts is changed. Main's mounted tests (InboxPage.test.tsx, InboxDetail.test.tsx, DraftsView.test.tsx) and its five tests/browser/inbox* specs were written against client-decided rows and main's read-state fixtures. They are restated against the relay's answers. Cases that pinned behaviour this PR drops (the read archive, per-message read receipts) were decided one by one: restated to the new rule where there is one, removed where there is not.

Which channels are skipped without asking

The Inbox may ask the relay about at most 100 messages at a time. To spend those on channels that can have a row, a channel is skipped when its sidebar row proves there is nothing in it. A row is that proof only if all of these hold:

• its attention count is exactly zero,
• its request started after the last event cached for that channel, and
• it has cleared any unread live hint for that channel.

A queued, in-flight or failed sidebar read proves nothing, and neither does a row older than the newest cached event. What this rests on is reading the source and unit tests with mutants, not a run against a real relay. The sidebar row and the per-message answer come from two separate responses, and nothing makes the pair atomic.

A message the relay has not answered for yet keeps the snapshot unresolved (stale, no error) and has no row. A message that cannot be asked about (unavailable, or ancestry that cycles, is too deep or crosses channels) is skipped and does not hold the snapshot open.

Named limit: the 100 newest

The 100 questions go to the newest messages from other people in channels not proven empty. An older mention with 100 newer cached messages ahead of it gets no row, and the snapshot reads stale instead of complete. This is pinned by a test (100 newer gives no row, 99 gives a row) and written in docs/inbox.md. Removing it, and item 8 above, needs the relay to list what needs attention. That is a follow-up to block/buzz#7906, agreed with Tyler, and not part of this PR. "Ready" here means the bounded candidates have answers. It does not mean a complete historical Inbox.

Notification and open-message subscriptions come first under the shared context limit. They take an Inbox question only when they would not otherwise fit.

For anything else built on the Inbox

• status and freshness must be honoured: stale means the list is not known to be complete. An empty list is not "nothing to do".
• The feed and the verdicts are two subscriptions with two statuses. A finished feed does not mean the verdicts are in.
• An empty readThrough on a channel row means "no Inbox read action". Do not substitute a channel read or a single-message receipt.
• Open a row with messageId and rootId together. They are a pair.

One fix beyond the cutover: a focused message keeps focus while the list re-measures

• What went wrong. The message list hides each item until its new position is measured. When the item holding keyboard focus was hidden that way, focus dropped to the page and nothing gave it back. It showed when a DM was opened from the Inbox and its first history load returned messages both older and newer than the opened one. CI caught it once at c70aec6a (inbox.spec.mjs, Chromium).
• The fix is five lines of CSS in Messages.module.css: a message whose list item contains focus stays visible. The rule uses :has(:focus) on the list item, not :focus-within on the message. The message action bar is drawn in the top layer, and with a control in that bar focused, :focus-within on the message measured false on both engines.
• Evidence, both engines, one worker, no retries. The existing test now holds the history load until the row has focus, so it reaches the failing order every time. Without the rule it fails 5 of 5 on Chromium and 5 of 5 on WebKit. With the rule it passes 20 of 20 on each. Five new cases in inbox-row-focus.spec.mjs cover focus on the row's action button, focus on a control in a later row, focus a person moves elsewhere while the row is hidden, Escape, and the Inbox withholding the conversation. Without the rule four of the five fail on both engines, and the fifth passes either way, as it should. With the rule all five pass 20 times per engine. These counts were taken on the parent commits with the same CSS and test bytes applied. At this commit the files passed once per engine locally and once per engine in CI.
• Where the row is drawn while its item is hidden. With measurement delayed on purpose, the focused row was painted at the same position before and after measurement, on both engines. In that probe the row above was already measured. Not covered: a focused row below rows that are not yet measured, and a focused row taller than its estimate above a visible row.
• On main. The list hides items the same way on main, so by reading the source the loss is reachable there through other inserts. It was not shown on main at runtime: in that test main's Inbox opens the older DM and never reaches this order.
• Left alone: a defect main has too. After the Inbox withholds a conversation and then recovers it, focus is not handed back to the row that had it. It fails the same way on main 8e371726 and on this branch, 4 of 4 runs each across both engines. The row's element is replaced during recovery, so the hand-back has nothing to focus. InboxDetail.tsx is identical to main. Not fixed here. The new test stops before that step, and an issue is drafted.

Known limits in this version

• A failed small sidebar update is not retried. When a targeted sidebar read fails, its channels are not read again until the next full roster read, normally within the 60 second cadence while the tab is visible, or on focus or reconnect. There is no guaranteed bound under continued failure. Main counts from live events and has no such dependency. A fix was sized (one full refresh after a failed read) and left out because it turns one failed request into 7 to 50 while the relay is already failing.
• A read made in another session arrives on the next full roster read, not at once. In the live pass a read in one session reached the other after 59.8 seconds. That is one observation on a healthy relay, not a bound. Main's latency for the same thing was not measured.
• A relay rejection of an already saved read (blocked or invalid) is recorded but not shown. The channel is read again and the count coming back is the feedback.
• An Activity preview is read when the popover opens: it is not live, and it takes the newest 500 edits across the listed replies.
• After a deletion, the app refreshes only the channel named on the deletion event. Buzz never sends a deletion that spans channels.
• Automatic reading that cannot be saved (journal full) stops without a notice. Explicit actions show the error.
• An Inbox row can show a message's text from before an edit after a reconnect. This applies to a DM or conversation reply that does not tag you. Main re-read recent edits on reconnect, and this PR removes that read with the client's own unread store. The row catches up when another read or a live delivery brings the edit. A deleted original leaves the list on the next successful refresh. Rows for messages that tag you are still checked for edits and deletions. This was found by reading the source and was not reproduced in a browser. It is written in docs/inbox.md.

Test changes a reviewer should know about

• A known WebKit log is allowed during a confirmed page replacement. When a page reloads, WebKit can log the departing page's sidebar read as Fetch API cannot load ... due to access control checks without Playwright recording the request. tests/browser/page-errors.mjs now excuses that exact message for that exact URL, at most once per main-frame navigation, and only when the same navigation then commits a new document. A genuine denial of that read from the old page in that interval (about 0.1 to 0.2 seconds) is an accepted blind spot. This is a test-watcher allowance, not a fix. Without it the error appeared in about 1 in 3 WebKit runs of one reload journey.

• The allowance reads a Playwright internal. New-document identity comes from the client frame's private "navigated" event (newDocument.request), because the public framenavigated does not carry it. @playwright/test is pinned to exactly 1.63.0. If the internal changes, nothing is excused and the failure names the internal. docs/contributing.md says to recheck it when upgrading. Playwright preserves the order WebKit delivers events in. That WebKit sends the log before the commit is observed, not guaranteed.

• The drift report can also fire for a test's own timing. By reading the watcher, two shapes would produce it with no Playwright change: a main-frame navigation requested before the previous document fires domcontentloaded, and a navigation with no new document (a download or a 204) followed by setContent. No spec does either today. Sami ran 60 real-WebKit rows across superseded navigations, 204s, downloads, redirects, routed responses, history moves and setContent with no false report.

• A sidebar pause on page exit was tried for the same error and removed. Over 30 WebKit runs each way it took one reload journey from 11 errors to 0 and another from 0 to 2. The reader's existing pause is unchanged from main apart from the removed read-state snapshot.

• Browser fixtures now use UUID channel ids. Specs that named channels by label ("alpha", "beta") were adapted, and each merge with main brought more.

• Nine merges with main since b2f8d23a: c9946be4, f432088a, 8eca3958, e38d5405, 0fb09ceb, 85c7f392, 512a9c2, e8c21196, 8e371726. The first brought the Inbox data layer. The second conflicted in 16 files: 12 browser specs, websocket-actions.profile.mjs, ChannelSidebar.test.tsx and two Tauri permission files. Specs keep this branch's UUID ids and real read actions and take main's openChannelDetails helper (feat(channels): unify header actions and inline details editing #487) and the main fix: pause the clock while an Activity-opened thread must stay unread #548 clock pause. The Tauri files keep main's new permission and do not restore the three removed read-state commands. The third (Defer untouched desktop message action bars #528) merged without conflict. The fourth brought the Inbox page (Show exact Inbox conversations with read recovery #499) and conflicted in MessageRow.tsx (two import lines), fixture.mjs and docs/inbox.md. The fifth brought Drafts (Resume scoped drafts in Inbox and discard deleted attachments #502) and conflicted in InboxPage.tsx (one hunk, indentation against the captured item), docs/inbox.md and two specs. The sixth (fix(runtime): bundle Goose-compatible Buzz MCP server #547, Polish composer typing indicators #551) conflicted in one hunk of inbox-drafts.spec.mjs, where main and this branch had made the same fix. The seventh (Add Canvas history and confirmed restore UI #552, Canvas history) merged without conflict. The eighth (Add trusted enterprise relay discovery #524, Make bundled plugin defaults explicit and hide unavailable entry points #557) conflicted in the import blocks of layout.spec.mjs and sidenav-polish.spec.mjs. Both keep this branch's UUID ids and take main's new per-spec Bestie opt-in. The ninth (Allow plugins to unregister (kind 5) owner-managed agents through native services #536) merged without conflict and brings three native-side files.

• Most of what the merges broke, Git did not report. Main's new tests name channels by label, which this branch's fixture rejects, or use fixture helpers this branch replaced. Found by reading every test main touched: six sites after f432088a (channel-header-menu, channel-members, one stale settings click in websocket-actions.profile.mjs), five after 8eca3958 (message-actions 3, startup 2), the four Inbox specs and seven sites in inbox-drafts.spec.mjs (main's bytes fail 12 of 12 and 4 of 4 on this tree), six type errors in DraftsView.test.tsx, the two mounted Inbox test files (they imported the removed read-state fixtures), and two event tags in canvas-history.spec.mjs (main's bytes fail, the editor stays empty). Found only by running the browser: main's startup test (Animate Buzz startup through initial content readiness #534) called a fake-relay helper, holdUnread, that this branch replaced with a hold on the sidebar API. Also found only by running: Show exact Inbox conversations with read recovery #499 brought a second, earlier thread_window handler into tests/browser/fixture.mjs. Git merged it cleanly. It answered before this branch's strict handler and left out older joined replies, so one thread test showed 2 rows where it expects 3. The 67-line duplicate is deleted and one handler remains. One more was a label id inside a test, rejected by the sidebar journal and swallowed by a .catch that main has too, which made a read test look like a product failure.

• Two races in main's Inbox specs are closed with waits, not delays. inbox.spec.mjs asserted on a revealed message one frame before the reveal's confirming frame. Without a two-frame wait it failed 10 of 25 Chromium runs, with it 0 of 25. The step order is main's, and it was not measured on main. In inbox-drafts.spec.mjs the keyboard helper focused Send while it was still disabled (a thread draft enables Send only after its saved root is verified, about 30 ms later, and focusing a disabled button does nothing). It failed 1 of 39 WebKit runs here. Main made the same fix in Polish composer typing indicators #551, and the merge keeps main's wording.

• Four browser tests were repaired after the first CI run, at 54809c01, went red on them. All four faults were in the tests. Two message-menu tests (message-management, agent-activity) raced the app's automatic read, so the menu correctly offered "Mark unread" where they expected "Mark read through here". They now wait for the automatic read, mark the message unread, and then exercise the manual action. One thread-history test installed its fake clock and then paused it at a time already past. It now lets pauseAt install the clock. The fourth is the typing test in the next item.

• edge() in tests/browser/timeline.mjs, main's helper from fix(messages): stop three timeline scroll races that flake CI #456, gains one optional position argument. edge() hovers the scroller's centre before it wheels. On this branch the thread typing test must wheel about 316px back to the bottom (threads open on the newest window, and the test scrolls up for older replies first). On Linux the centre lands on the hovered row's floating toolbar, and a wheel over that toolbar does not scroll the thread. The test now passes { x: 100, y: 100 }. Callers that pass nothing hover the centre as before. The toolbar's source is unchanged from main, and its wheel behaviour is not changed here. The evidence is from macOS with a 10px border standing in for Linux's scrollbar gutter: main's call alone fails, the positioned call passes. No local Linux run. CI is the first.

• The merge with main e5a70460 conflicted in 11 browser specs and dev/relay-broker.mjs. The specs keep this branch's UUID fixture ids and take main's new scroll helpers and fixed-base clocks. The broker keeps Discover saved identities across joined communities with names, pictures and retry #291's agent-inventory route and does not restore the removed read-state routes.

• Since 9bfa2af3, three small repairs. sidebar-unread.spec.mjs holds reading focus before its explicit sidebar read (+2 lines). profiles.spec.mjs waits for the closing profile dock before its second Members click (+3 lines). In production code, unread.ts no longer starts the full sidebar walk that a cached roster would discard, which ran the walk twice after a reload.

• The browser fake relay applies the reply rule. tests/browser/policy-relay.mjs answers with reason, the direct-parent conversation rule, undecided replies and filtered previews, and thread-unread.spec.mjs covers joined and unjoined threads.

• CI at c70aec6a went red on three browser tests. Two are repaired here and one is main's.

  • inbox.spec.mjs "reveals an older exact unread anchor", WebKit: the test raced the app's 300 ms read dwell. A control proves it: a 1 second wait before Close fails 10 of 10. The repair (+15 / -2) separates the read arriving from the later reopen. With it, 40 of 40 per engine.
  • inbox.spec.mjs "an in-head DM keeps exact focus", Chromium: the focus loss fixed above. It was the product, not the test.
  • navigation-groups.spec.mjs:75, WebKit: a race in the test, with the same steps on main. The test holds a response itself and starts its 10 second wait before it releases the hold. It lost by 0.16 seconds. Not changed here. A repair (+7 / -3) is prepared as a test-only change for main.

Open reds and gaps, named

• Three browser tests failed once each in the last full local run, at 618600f4. I judged all three test timing races, not effects of this PR, and did not change them here. All three passed on both engines in CI at this head. They can lose again. Repeat counts, no retries:
  • activity-navigation-focus.spec.mjs:97 (reply variant), Chromium. Passed 20 of 20 on rerun, at this branch and at the branch before the suspected change. A probe in the page shows why it can lose: opening a thread on an exact message moves focus to that row a median 37 ms after the panel shows, and the test's menu click lands at 70 to 100 ms. The menu closes when focus leaves it. The margin was as small as 24 ms.
  • inbox-revalidation.spec.mjs:18, WebKit. Passed 18 of 20 here and 39 of 40 on main e8c21196 with the same signature: a paused video's currentTime ends 5 to 17 ms past the value the test read inside pause(). Too few runs to say the rates differ.
  • timeline-setup.spec.mjs:221, WebKit. Passed 20 of 20 on rerun. Not reproduced. It loads no app code.
• The first of those points at a real focus bug that main has too. The reveal that focuses the target row runs whenever the thread window finishes loading. On the fixture that is about 14 ms. On a real relay it is as long as the load takes, so a person can open a menu in that gap and have it close. The reveal code is the same as main's. Not measured on a real relay. Not fixed here. A test-only wait for it exists and is kept out of this PR.
• dev/media-preparation.integration.test.mjs "tiled HEIC preparation preserves the full image dimensions" fails locally (expected 1536x1024, got 512x512). It is the only local Vitest failure at this head. No CI job checks it. The CI unit job has no ffmpeg, and the test returns early there (skipping real conversion: ffmpeg not found), so its pass in CI says nothing. What shows it is not from this PR: the converter, the test and the fixture are the same blobs as on main 8e371726, it failed the same way on this machine on clean main 75e6dc39, and this machine's ffmpeg 8.0.1 produces 512x512 from the fixture with no app code. It is main's test from feat(native): add community extras and media preparation #450. An issue is drafted.
• An old DM that the feed admits beside a newer loaded head can show without a gap marker between them. By reading the source, main has the same path (store.ts is identical). Not reproduced on main. Not changed here.
• navigation-groups.spec.mjs "Create new ... partial failure" timed out once in 30 instrumented WebKit runs: after a reload, fill("Follow-up") did not reach the field. Cause not established. Three assertions (focus, no menu, value after fill) were added as a diagnostic, not a fix. It passed on both engines in CI at this head.
• Not covered by any passing test on WebKit: read behaviour when a mailto: link or a download keeps the page after beforeunload. Chromium covers both.
• No matched performance comparison was run. No profile ran unchanged on both main and this branch (main's fixtures used label ids, this branch uses UUIDs, and the two select different thread traversals). Main's new scenario runner (feat(profile): run an unattended scenario file in web profiling #476) can drive one unchanged real-relay scenario on both. That run is a follow-up.

What to review

• docs/unread.md and docs/inbox.md against the behavior above. If they disagree, the doc is the bug or the code is.
• The four owners and nothing else holding read state: sidebar-api.ts (wire), sidebar-state.ts (projection and flush), sidebar-journal.ts (durable intent), unread.ts (selectors and intents).
• The Inbox binding: subscribeInbox and the candidate selection in unread.ts, the context demand it shares with notifications in sidebar-state.ts, and the captured visit in InboxPage.tsx. Against main, inbox-feed.ts and inbox.ts change by +5 / -4 lines between them and InboxPage.tsx by +12 / -11.
• That no local counter or fallback survives. At 2ebfeb79, buzz-read-state, readStateSnapshot, relay_decode_read_state, read-state-model and clearUnreadLocal have no hits under src, src-tauri or dev. Each has hits on main 8e371726.
• The "Relevant replies" section of docs/unread.md against feat(relay): private read-state accessory API buzz#7906's docs/buzz-v1-read-state.md. Both must name the same four reasons in the same order.
• Size against main 8e371726: production 48 files, +2,805 / -4,592. Tests and test fixtures 125 files, +12,581 / -9,337. Docs 7 files, +447 / -484. One workspace config line (+3).
• Of that, binding the Inbox data layer to the relay was about 380 touched production lines (+343 / -39, measured at the first Inbox merge). About 280 lines of main's feed and types are kept as they are.

Evidence at the pushed head, 2ebfeb79

• Contains main through 8e371726 (Allow plugins to unregister (kind 5) owner-managed agents through native services #536). Pushed as a fast-forward from c70aec6a, no force push. Main was still 8e371726 after CI finished.
• Typecheck, lint, design types, the design-system guards and the build: all exit 0 at this exact commit.
• Full Vitest on this exact tree: 7,119 pass, 1 fail (the tiled-HEIC test above), 1 skip. 508 files pass, 1 fails, 1 is skipped.
• CI at 2ebfeb79, read per job: 21 jobs succeeded and Windows native validation is skipped. That is all 12 browser shards, both JavaScript jobs, Rust and tool integration, Native browser fixture, Browser measurements, CI required, DCO, Semgrep and zizmor. One shard, Chromium 6 of 6, needed a second attempt. On the first, its setup step failed downloading Hermit (HTTP 500 from GitHub releases) before any test ran. The rerun passed 86 of 86.
• Browser journeys in CI at this commit, every spec file: Chromium 600 passed, WebKit 600 passed. No shard log shows a failed or retried test. The three tests that were red at c70aec6a and the five new focus cases passed on both engines.
• Browser journeys locally at this exact commit, the nine files that exercise the changed CSS (every Inbox spec, both message-action specs, the scroll spec): 38 of 38 on Chromium and 38 of 38 on WebKit, one worker, no retries. The whole suite was not run locally at this commit. The last whole local run was at 618600f4.
• Source review by Wren of every merge and repair on the way to this head, including each of the four commits since c70aec6a: no open blocker. Wren read the whole production diff against main 8e371726 in one pass at c70aec6a, against docs/unread.md and docs/inbox.md. Production code has changed since then by the five CSS lines only. These are source reviews. They ran nothing.
• Paired live pass, the real app at this commit against a relay built from feat(relay): private read-state accessory API buzz#7906 ce9481aa6, Chromium and WebKit: both passed, one attempt each. It opened the Inbox on a real relay: a fresh thread mention got a row, the click revealed and focused the exact message, the thread read was applied and confirmed by a separately signed relay read, the thread's root stayed unread with no reason, the row left the list and the opened conversation stayed open. The sidebar counts, thread previews and reasons for a never-joined thread, an own-parent conversation, a mention and a DM passed too. No page or console errors. Each engine's log prints both commits before the run and the app commit again after it. The relay's reported source and its binary hash are checked at the start of each engine. One caveat: on Chromium the harness failed once to capture a response body, before the Inbox steps. Which request it was is not known. Every assertion passed without it. It is one scripted path, not the browser suite. It does not cover a cold-start DM, the 100-question limit or Drafts.
• Clippy at this commit in CI (--workspace --locked --all-targets -D warnings): passed. It was not rerun locally. No Rust file has changed since c70aec6a, where it exited 0 locally. The branch's Rust change against main is seven files, nearly all deletion of the old read-state commands (+5 / -324).
• Hooks. Every commit from 7b32c538 through c70aec6a ran the repository's staged checks under the pinned Lefthook and passed, and so did the fix and the Inbox docs commit since. I did not check the hook runs of the other two new commits (one docs, one test repair). 7b32c538 itself was made with the hook bypassed, because the machine's Lefthook was older than the repository requires. Its tree was checked by hand, and every later check ran on trees that contain it. On the pushing machine git push runs only the organisation's push check, not this repository's check-push group. Of that group's three steps, typecheck with the full unit suite and the design checks were run by hand at this commit, and Clippy ran in CI, as above.
• Not covered by any run: the packaged desktop app, the OS keychain, Git storage, a relay with NIP-FI in Enforce.
• The five review threads from 9/29 answered. Four are fixed in commits on this branch (d9180639, e814f374, 43428274, e15e1857). The fifth is item 9 above (old read positions and Mark-unread marks start over once). No code answers it. It is a product decision and it is open.
• A person has used it.

Originating Buzz channel 6f773b94-34d0-4004-bec9-a100b6ad17d5.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: five P2 findings inline. Reviewed frozen head 1b27a5cc92c20a4b485abc67c65083bbc0bcde78, not the unpublished main-integration work.

• Evidence: focused production-source reproductions for all five findings, including the real local HTTP broker/transport boundary and isolated Chromium IndexedDB. No product edits. These probes are not a full app or native acceptance run.
• Remaining gates: GitHub currently reports merge conflicts; visible hosted checks are Semgrep OSS, zizmor and DCO, not app integration CI. The PR already discloses the unpublished compatible relay extension and unfinished merged-tree/performance/human acceptance. I have not reclassified those disclosures or unexplained browser failures as new defects.
• Exit criteria: address the inline defects with regressions, then validate the integrated app against the published matching relay contract and complete the disclosed acceptance gates before readiness. An intentional legacy local-intent reset requires explicit product approval.

[wesbillman]

[P2] Keep sidebar-specific 503s out of the shared API cooldown

This promotes every sidebar 503 (even without a retry header) into a pause of the same admission lane used by history queries and other relay HTTP operations. A sidebar-specific timeout or storage failure consequently disables otherwise healthy reads. I reproduced this through the production broker and transport: /me/sidebar returned 503 with Retry-After: 60; the immediately following history query() returned 429 with ~60 seconds remaining, without making any upstream /query request. Already queued work is also rejected by pump().

Preserve the retry hint for the sidebar owner, but do not pause unrelated operations for a non-quota 503. Keep shared backoff for the actual shared-quota refusal, and cover an unrelated query succeeding after an accessory failure.

[wesbillman]

[P2] Coalesce invalidations while a targeted refresh is in flight

Clearing dirty and dropping ownership of the launched refresh permits another targeted pass every 250 ms, while schedule() appends each pass to its unbounded serial promise chain. With request latency above that interval, a busy channel accumulates redundant reads ahead of context/notification reads and roster refreshes. The transport's concurrency limit cannot help: these jobs have not reached it, and their 10-second timeout starts only when dispatched.

A controlled-timer reproduction against this head held the first targeted request, fired six more invalidation windows for the same channel, then released it: seven targeted requests, rather than the initial request plus one coalesced follow-up. Keep a single in-flight target drain and retain dirty IDs for its next pass, as the context-refresh owner already does; add the held-request regression.

[wesbillman]

[P2] Preserve durable local unread marks during the database cutover

Existing profiles saved explicit manual-unread intent in buzz-read-state-v1 (partitions[scope].localUnread). This opens only a new database, and the removed owner is the only reader of the old records. Upgrading therefore silently removes those reminders from the UI, despite manual unread remaining a durable, device-local feature. This is separate from the intentionally unsupported legacy relay-counting fallback.

In isolated Chromium IndexedDB, I seeded a valid legacy channel mark, then loaded the production new journal with the same scope: manual became [] and manual(channel) was false, while the old mark remained on disk. Add an idempotent migration for directly resolvable marks, retaining recovery data and surfacing any entries requiring resolution. A deliberate reset instead needs explicit product approval and user-facing disclosure, not an implicit empty journal.

[wesbillman]

[P2] Retarget retained message demand when ancestry changes

This lease captures context(message) once, but attention() and the message snapshot resolve it again on each read. A valid reply-only child can initially resolve to its unloaded immediate parent; when that parent arrives carrying the canonical root, the selector moves to the root while the retained query stays on the parent. subscribeMessages() has the same mismatch.

I reproduced this with signed child/parent events: attention was initially eligible, became unknown after parent arrival, and remained unknown after explicit refresh because the only query still targeted the parent. A notification candidate waiting on this lease can remain unknown until expiry; refreshing does not repair it. Reconcile retained targets with changing ancestry (including evidence loss), keeping selector lookup and demand ownership consistent, and cover late-parent arrival without requiring an unsubscribe/resubscribe.

[wesbillman]

[P2] Track write health independently from projection refresh status

flush() sends failures into the same sync.status/error that refresh() owns, but a successful flush never clears that failure. I reproduced both orderings: (1) an unknown acknowledgement followed by a successful later flush leaves {status:"error", pending:0, error:"Read acknowledgement unknown…"}; (2) a write failing while traversal is held becomes {status:"ready", pending:1} with no error when the traversal completes.

The first marks otherwise usable projection evidence stale and makes notifications wait until a separate refresh; the second hides the failed-write/retry reason behind ordinary pending state. Keep write failure/recovery separate from read freshness, so an unrelated read cannot erase a write error and a completed successful flush clears its own error. Cover both interleavings.