[morgmart]

Relay side: block/buzz#8575 (merged). Replaces the closed #1602, rebuilt on current main.

What

When you add several people to a chat at once, Buzz now sends one relay write for all of them instead of one per person, then checks the member list once.

This covers every place the app adds several people together:

• Sharing a chat with a channel or DM
• Add team in Members
• Inviting people you mentioned who aren't in the channel
• Bringing several agents in from another community

How it behaves

• One write per role, up to 100 people each. People and agents go in separate writes because they join with different roles. The relay accepts at most 100 people in one write, so bigger groups are split.
• The member list decides. After the writes, Buzz reads the member list once. Anyone not on it gets today's one-person add, which shows their own error and Retry. Older relays that only add the first person in a write still end up with everyone added.
• A batch is never sent again. If a batch is left in Outbox (for example, the app quit mid-add), Retry re-adds each person through the normal checks. The batch stays in Outbox until everyone it names is in the chat or has their own saved add, so a failure or restart never loses anyone. A stale role can't overwrite someone's newer role (feat(channels): control participation and preserve guest reading #1882, fix(channels): preserve access roles and recovery focus #1948).
• Earlier adds keep their own path. Someone with a one-person add still pending keeps it. In a Solo chat, agents always get their own add, so a share that resumes after a restart still finishes the agent's Bot grant (fix(channels): preserve access roles and recovery focus #1948).
• Members additions made at the same moment for the same channel share a batch. A single add behaves as before.

Not included

Tagging several agents in the composer still adds them one at a time. That path uses a separate add mechanism with no saved receipts, so batching it means redesigning how it recovers. Better as its own follow-up.

Testing

• New tests, each failing on main before this change:
  • a share to a channel with several members goes out as one write, on a relay with and without batch support
  • 101 people plus an agent become 3 writes: 100 members, 1 member, 1 agent
  • a relay that only adds the first person gets the rest added one by one
  • additions requested together are batched, and the rest are added singly
  • Outbox Retry of a leftover batch re-adds each person and clears it, even when one person fails
  • inviting mentioned non-members and bringing agents request everyone together
  • a Solo chat's agents keep their own add
  • a pending one-person add is resumed, not batched again
• If a write fails before it's sent, the member list is still read again before the next write (fails if that re-read is skipped)
• A guarantee test that also passes on main: when a batch fails, everyone is added singly.
• Rebased on current main at db8491d and squashed into one commit, since main now has the guest and Solo member roles (feat(solo): open chats for community viewing #2107, feat(bestie): choose the private channels Bestie can read #2036). Batches follow the same role a single add sends: an explicit Guest stays Guest, agents are Bot, and Solo and private-channel people are Member. Web signing accepts Guest batches. Outbox Retry keeps a guest batch Guest and keeps single retries receipt-only. A Retry never joins a batch. A Solo chat's resolved no-role invitation stays with the single add, which reports a Guest outcome; that has a new test, checked to fail without the fix. Type check and biome pass. Every test file this PR touches passes. Full-suite runs on a heavily loaded machine had rotating timeouts in unrelated areas; each passes when run alone, so CI is the full-suite check.
• No UI changes; Outbox's Retry button works as before, so there are no screenshots.
• Not yet done: a human trying it in the running app, and a live run against a batch-capable relay.

🤖 Generated with Claude Code

[kalvinnchau]

🤖 Two correctness defects and one recovery-label mismatch remain in the multi-member flow.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, integrating Rocket (systems/lifecycle), Mantis (correctness/security/concurrency), and Groot (product/recovery).

One P2 recovery defect is detailed inline. The previous roster-refresh, browser-signing, batch-label and failed-dispatch-test feedback has corresponding source changes; no duplicate findings are raised for those items.

Reviewed head 706f692bc5c9dfef678eb795538de189e4061fc7, base 1c88d190f98ec7eec5b08c99aadf2460e644967f, feature merge-base 1e65c90662f655c37d83112076c6d8639ae0c984. Reviewed the 17-file feature patch, callers, recovery ownership, PR description and commit messages; the description contains no image attachments. No concrete public-material disclosure finding.

Source-only: no local tests, builds, app execution, live relay, native accessibility/focus or human acceptance testing. One hosted-check snapshot showed CI required passing, with Windows native validation and browser flake checks skipped; this does not verify the failure case below. This is a COMMENT review, not approval or merge authorization.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating Rocket (systems/lifecycle), Mantis (correctness/security/concurrency), and Groot (product/recovery).

No new actionable findings in this recovery fix. The previous P2 is addressed in source: batch acknowledgement now waits until every recipient is roster-confirmed or covered by a replacement addition, and Outbox Retry delegates settlement to that owner. The outbox saves the current journal before releasing batch recovery.

Reviewed head a9706d59248b75d86ec81981f13d55eb1fadba9a, base 1c88d190f98ec7eec5b08c99aadf2460e644967f, feature merge-base 1e65c90662f655c37d83112076c6d8639ae0c984; follow-up compared directly with 706f692bc5c9dfef678eb795538de189e4061fc7. Checked the five-file follow-up in the feature/caller context, public PR description and commit messages; no attached images or new disclosure finding.

Validation remains incomplete. A single hosted-check snapshot showed CI required failing: WebKit shard 3/14 reports opening/closing text shifts in tests/browser/message-actions.spec.mjs:101. Causality was not established. Windows native validation was skipped. We ran no local tests, builds or app/relay execution; native focus/accessibility, real storage/restart recovery, performance and human acceptance remain unverified. The new recovery test inspects saved records and retries within one session, rather than exercising a restart.

COMMENT review only; no approval or merge authorization.

[wesbillman]

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

No blocking findings at a9706d59 (base main at 4293f6da). There are two optional suggestions, inline below.

Independent review lanes checked:

• Outbox and recovery. Scratch repros of an app restart after the relay applied a batch: Retry confirmed everyone from the roster without sending the batch again. A saved batch is never resent, so the stale-role problem from #1882 and #1948 can't come back. A batch is acknowledged only once everyone it names is in the roster or has their own pending add.
• Relay contract, compared with the block/buzz#8575 handler: the 100-person cap, the role fallback, the first-person-only fallback on older relays, web signing including the single-Bot path, and roster reads after refused or unknown writes.
• Callers: sharing, Add team, inviting mentioned nonmembers, bringing agents, and keeping Solo agents on their own add.

The review was source and scratch-test only. CI is green. As the PR notes, nobody has yet tried it in the running app or against a batch-capable relay.

[wesbillman]

Optional: a kept batch can stay in Outbox for good. Repro: on an older relay only the first person is added, and the roster read afterwards fails, so the batch is kept as accepted. Then the viewer loses add access, or the channel or a named person is archived. From then on Retry always fails, and Remove from outbox fails with “Confirm this addition in Members before removing it”, but Members has no way to confirm a batch. A single add can already get stuck like this. What's new is that this row offers a Retry that can never succeed, the Remove message points somewhere that can't help, and the batch keeps using a pending slot. Suggested fix: allow Remove for a batch once the viewer can no longer add to the channel, or once Retry finds nobody it names who can still be added. At minimum, give batches their own Remove message.

[morgmart]

🤖 Morgarita, Morgan's AI agent: agreed this is worth fixing. We're leaving it to a follow-up so this PR's approved scope stays put.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating Rocket (systems/lifecycle), Mantis (correctness/security/concurrency), and Groot (product/recovery).

No new actionable findings in the archive-race fix. The batch now rechecks archive visibility after each awaited roster read, immediately before dispatch. Missing recipients excluded by that check retain the existing single-addition error path; sharing to a channel audience intentionally skips archived identities. The added regression test models an archive snapshot changing during the first roster read. Previous feedback is not duplicated.

Reviewed head e4dab006f58f0fa8cd7b467b7c5c5178133ab6d3, base 1c88d190f98ec7eec5b08c99aadf2460e644967f; compared directly with previously reviewed a9706d59248b75d86ec81981f13d55eb1fadba9a. Scope: the two-file follow-up and its batching, membership, sharing and recovery callers. Public PR description and commit messages inspected; no attached images or concrete disclosure finding.

Source-only: no local tests, builds, app execution or live-relay validation. A single hosted-check snapshot showed 34 successful, four running and two skipped checks; CI completion, real archive-refresh/retry behavior, native focus/accessibility, performance and human acceptance remain unverified. COMMENT review only, not approval or merge authorization.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating Rocket (systems/lifecycle), Mantis (correctness/security/concurrency), and Groot (product/recovery).

No new actionable findings in the rebased batching integration. Batches use the same role selection as single additions, preserve explicit Guest intent, and leave pending single receipts and resolved legacy Solo invitations to their existing recovery path. Single Outbox retries stay receipt-only and do not enter batching. Earlier feedback is not duplicated.

Reviewed head 7455ba4c8ece5181795ae907cc98b6ecf1c23acd, base 0b2dfbf9889ea95873f175b216fbb0b5795f104e, feature merge-base db8491da1452b47b76faca6703d9f40c1abf73a4. Scope: the 17-file feature patch, its changed integration with current Guest/Solo behavior, supported callers and durable recovery. Compared feature files directly with previously reviewed e4dab006f58f0fa8cd7b467b7c5c5178133ab6d3; this is not a review of every intervening upstream change. Public PR description and feature commit text inspected; no attached images or concrete disclosure finding.

Source-only: no local tests, builds, app execution or live-relay validation. One hosted-check snapshot showed 39 successful checks and two skipped. Actual restart/storage-failure recovery, batch-capable relay behavior, performance, keyboard/focus recovery after errors and human acceptance remain unverified. COMMENT review only; no approval or merge authorization.