[matt2e]

Two relay-client limits failed outright once a community passed them. Each now returns what fits.

	Cliff	Before (main)	After (this branch)	How real
(a)	profiles.ensure asked for more than 1,024 ids	Threw "Profile request exceeds the directory budget" before reading anything. Community admin raised an unhandled rejection and its name search found nobody. from: search in a channel failed with the same message.	Names the first 1,024 ids in three reads (500/500/24). Members past the cap keep their public-key label. Callers catch a failed batch. from:name checks the relay for namesakes past the cap instead of silently picking the loaded one.	Happens today. #general has about 2,500 members (#1828), and auto-join channels grow with the community.
(b)	Opening a message by exact id with 500+ reactions (Inbox, search, reminder, deep link, message-link preview, media viewer)	"Selected message exceeded its evidence limit"	Opens with the newest 500 reactions. Edits, deletions and moderation overlays still fail closed at 500.	Plausible as usage grows. The relay keeps one reaction per user, emoji and message, so 500 is about 20% of #general reacting once.

Each failure was recorded in the running app on main, and each works on this branch (videos below). Benchmarks show no measurable cost on paths that already worked.

Size: non-test source +68/−15 across 5 files. Docs +9/−1, tests +513/−20.

Rebase onto main (2026-11-04)

Main moved under this PR, and two of its changes removed the ground this branch stood on. The rebase dropped the affected parts rather than carrying them:

• Discovery preview eviction (the old cliff (b)) is gone. feat: scale task channel delivery (NEXUS-3721) #1574 replaced discovery's 1,024-entry metadata cap with a 256 MiB byte budget, so previews can no longer crowd out joined channels in any realistic session. feat: scale task channel delivery (NEXUS-3721) #1574 also pins the shortened-id fallback for a joined channel whose name does not fit, which this branch had changed to "hidden until named". Dropped: discovery.ts eviction, the pinned/holds hooks in store.ts, session.ts and channel-reference.ts, discovery-capacity.test.ts, the eviction tests in store-discovery.test.ts and channel-references.test.ts, and the recheck-scan commit that only tuned the pin.
• The Members dialog no longer hits cliff (a). fix(channels): bound large member list rendering and profile reads #2028 pages the dialog's name reads (50 rows per page), so the dialog's "viewer first" request and its 1,100-member test are gone. The directory change still matters for Community admin and from: search.
• Adapted: upstream's verified-profile.test.ts expected a 1,025-id request to be rejected before verification (fix(relay): reject over-budget ids before verified lookup and evict in one pass #2220); it now checks that only the first 1,024 ids reach verification.

What changed

(a) Large rosters: profiles.ensure

• profile-directory.ts: a request above 1,024 ids (the cache's entry capacity) keeps the first 1,024 and leaves the rest unrequested instead of throwing. Fetching more would only evict names the same request had just loaded. No notice is shown for the rest, because Try again cannot name them. The verified-profile lookup gets the same sliced list, so an over-budget request never floods it (fix(relay): reject over-budget ids before verified lookup and evict in one pass #2220).
• ensure reports a failed batch only after its sibling batches settle, so a caller that tolerates the failure sees every name that loaded.
• CommunityAdmin.tsx catches the optional name read.
• useSearchMessages.ts lets from: proceed on a partial directory, as the author picker in SearchResults already does. When the member names are partial (a member past the cap or in a failed batch is neither loaded nor known unnamed), a loaded match no longer settles it: the relay name search runs too, its results count only if they are channel members, and two matches open the existing author picker. A healthy roster takes the old path unchanged.

(b) Exact open of heavily reacted messages

• threads.ts: reactions move to their own [7] filter in the same overlay request. The relay applies limit per filter, so the request count is unchanged. Reactions cannot hide or change the target, so the exact-target guard in session.ts counts only non-reaction events. Safety kinds (5, 9005, 40003, 39005) and tombstone responses still fail closed at 500.
• The tombstone read sends overlay ids in parts of 900. A single #e list above about 975 ids exceeds the reader's 64 KiB filter budget, and a target with a full reaction page plus a few hundred edits reaches that. Up to 900 ids it is one request, as before.
• Reactions older than the newest 500 are not read. Live reactions keep arriving.
• tests/browser/policy-relay.mjs recognises the two-filter overlay batch so browser journeys that open a thread keep passing.

Docs: docs/channels.md covers the roster cap and the 8 MiB batch limit. docs/relay-queries.md covers the separate reaction filter.

Commits (messages cite pre-rebase SHAs)

Commit	What it does
9e14467	(b) Reactions get their own filter; the 500 guard counts only safety kinds
85835d3	(a) The 1,024 cap replaces the throw; batches settle before a failure is reported; callers catch
0f6c7bc	Review 1: drops reactionsCapped
7562d65	Review 2: drops halving, sends tombstone ids in parts of 900
1377891	Review 3: removes a slow duplicate test, simplifies a catch
040a39b	Policy relay stub models the split overlay read
236e628	Review 4: from:name checks namesakes past the cap
4fc0d5c	from:name looks for namesakes among unnamed members only

Evidence: before (main) vs after (branch)

Recorded in headless Chromium against a local buzz-relay (block/buzz 680b0a6b2) with seeded fake identities, before the rebase. The viewer is "Alex Chen". No production relay or credentials were used. Before is a3a6223; after is 98253fc4b. Each take starts from a fresh copy of the seeded database.

(a) Members dialog, 1,100 members

Recorded before #2028. It shows the directory cliff through the dialog, the most visible caller at the time; on current main the dialog pages its reads and the remaining callers are Community admin and from: search.

a-members-dialog-before-after.mp4

(b) Message with 500 reactions, opened from Inbox

Main fails with the evidence-limit error. The branch opens the message with its reactions.

b-500-reactions-before-after.mp4

Relay request log for the overlay read:

• Main: one filter, kinds [39005,40003,5,7,9005], limit 500. It returned 500 events, hit the cap and failed.
• Branch: two filters, [39005,40003,5,9005] and [7]. They returned 500 events, all reactions, and the message opened.

Review history

Round	Finding	Outcome
Review 1	A full reaction page set limited, so popular messages said "Thread history limit reached" while older replies still loaded	reactionsCapped dropped
Review 2	Halving a batch over the 8 MiB read budget was the most intricate code for an unmeasured case, and the 2 MiB cache would discard most of what it read	Dropped; listed under known limits
Review 2	Tombstone #e lists above about 975 ids exceed the 64 KiB filter budget	Fixed: read in parts of 900 ids
Review 3	Slow duplicate BuzzLinkPreview test; redundant rethrow in useSearchMessages	Removed
Review 4 (kalvinnchau)	from:name with more than 1,024 members resolved to the loaded namesake and silently read the wrong author's messages	Real; fixed. Partial names send the search to the relay too, restricted to members
Reviews 1–2, performance pass	Discovery eviction findings (open threads and mounted links losing their previews, a quadratic recheck scan)	Fixed at the time; the whole mechanism was dropped in the rebase (see above)

Performance

Measured in Node against the unit-test fakes with the production event verifier, before the rebase. Client times only.

Path	main → branch	Verdict
Exact open, fewer than 500 reactions	Same 3–4 requests, +98 filter bytes. 10 reactions: 13.0 → 13.5 ms with verification	No measurable cost
Exact open, 500 reactions	Error after 2 requests → opens in 4. Client verification 518 → 593 ms	Used to fail
Exact open, 500 reactions + 480 edits	Error → opens in 5 (two tombstone parts). 512 → 1,062 ms, to verify about 1,000 events	Used to fail
profiles.ensure, 1,024 ids	3 → 3 requests. 1,069 → 1,054 ms cold with verification	No measurable cost
profiles.ensure, 1,100 or 2,500 ids	Throws → 3 requests, 1,024 names, about 1.07 s	Used to fail
A profile batch fails	The rejection waits for sibling batches. Names present when it lands: 0 → 524	Acceptable
from:name, roster past the cap or a failed batch	One extra searchProfiles (limit 40) per debounced query, the cost the empty-match path already paid	Acceptable

Known limits

• No names past 1,024 ids. In Community admin about 1,476 of #general's members keep public-key labels, with no notice. On main every member did. The real fix is to read names only for rendered rows, as the Members dialog now does (fix(channels): bound large member list rendering and profile reads #2028).
• A batch over the 8 MiB read budget loads no names. Its sibling batches now do. Reaching it takes at least 31 maximum-size legacy inline avatars in one 500-author batch.
• Profile eviction is by insertion order. ByteLru never touches an entry on use. With a warm cache, a large request can evict the viewer's or on-screen names until those rows read again. Main already did this for requests of 600 to 1,024 ids.
• Only the newest 500 reactions are read on an exact open. An older reaction of the viewer's may not show as theirs in that view.
• from:name in a large channel: a name with 40 or more relay matches always opens the picker, and the relay does not fold accents, so an accented namesake past the cap is still missed.
• Untested against a real relay: 900-id #e lists. A rejection fails closed, as before.

Testing

• After the rebase (local, 2026-11-04): tsc, Biome on the touched files, and Vitest on every test file this branch touches plus verified-profile, store-discovery and channel-references: 159 files, 6,013 passed, 3 skipped, 1 failed. The failure (ChannelMembersDialog.test.tsx "expands local and relay groups…", 6.5 s) is in a file this branch no longer changes and passes alone (96/96); it timed out under the parallel load.
• Before the rebase: the broadest run, at a9c4ce4, covered src/features/relay and the suites of every changed consumer: 141 files, 2,725 passed, 4 skipped.
• Pushed with --no-verify. The pre-push related-tests hook times out under load on this machine.
• New coverage is all Vitest. No browser journeys were added or removed; the policy-relay stub change keeps the existing thread journeys passing on the split overlay read.
  • thread-target.test.ts: a target with a full reaction page and 480 edits opens, with tombstone parts of 900 and 80 ids.
  • profile-details.test.ts: names the ids that fit; a failed batch is reported after the others land. verified-profile.test.ts: only the first 1,024 ids reach verification.
  • CommunityAdmin.test.tsx, useSearchMessages.test.tsx (large-roster from:, namesakes on both sides of the cap, a namesake outside the channel, a fully read roster with no relay search).
• Hosts: the browser host was exercised before the rebase (Chromium, Vite dev server and Node dev broker, local relay). Not exercised: the native desktop host, WebKit, the rebased head in the running app, and exact opens from search, deep links and message links (only Inbox was used).
• Deferred: a human pass of the two flows on the desktop host. The review-completed marker is not in this description; the human adds it after that pass.

🤖 Generated with Claude Code

[kalvinnchau]

🤖 Four actionable findings: the browser relay model rejects the new overlay query, restrictive metadata eviction permits stale public replay, partial profile loading can hide author ambiguity, and the large-roster test is flaky. Fix these before merging.

[kalvinnchau]

🤖 Both previously reported P2s are repaired. One non-blocking common-name search regression remains.