Logan Johnson cd6b27483f Compute the member/bot label at read time and retire the roster trigger ...

`bot` has the same permissions as `member`; it only labels a key with a
recorded agent owner. Instead of storing that label and converting rows
when an owner is recorded, store `member` for both ordinary roles and
compute the label wherever a role is read: rosters, member lists, role
reads, DM participants and the bot list. An agent owner is recorded once
and never changes, so a key's label changes at most once.

- Writers store `member` for an ordinary role; reads show `bot` exactly
  when users.agent_owner_pubkey is set for the key in that community.
- The app-side roster fence treats `member` and `bot` as one role, so an
  owner recorded between roster capture and insert does not refuse the
  publication.
- After recording an owner, a background task lists the agent's active
  ordinary channels and republishes their rosters.
- BUZZ_RECONCILE_BOT_ROSTERS runs a one-shot startup repair of rosters
  that show a stale label (for example, ones older relays published).
  Nothing scans at every startup.
- Migration 0074 drops the 0032 roster trigger, which compared roster
  labels with the stored role exactly. Every relay must run #8611 first.

Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Logan Johnson <loganj@squareup.com>

2026-10-26 16:40:10 -04:00

..

src

Compute the member/bot label at read time and retire the roster trigger

2026-10-26 16:40:10 -04:00

Cargo.toml

feat(invites): add use-limited invite links (#3141)

2026-07-27 15:19:39 -07:00