feat(desktop): add team sharing to community catalog

[wpfleger96]

Stack: #5112 → this PR

Stacks on the team catalog backend PR (#5112). Contains the desktop/** changes that turn the add-agent surface into a single Community Catalog browsing both shared agents and shared teams.

Owner catalog sync pipeline

usePersonaSync.ts gains a hydration pipeline in startPersonaSync so a fresh device that comes online after another already published the owner's 30178 catalog head reconstructs the complete state without falsely retracting it. The owner's persona/team/managed-agent/30178/deletion history is backfilled up front (a live-only subscription gets no history — reconnect-replay's since-cursor is undefined until the first live event), then a live subscription takes over.

Four properties keep a fresh sync from purging the owner's valid shared head:

• Paged backfill with a safe termination guarantee. The relay serves each REQ newest-first and clamps limit to its advertised max_limit, so a large owner's history overflows one page — a newer 30178/30176 could return in-page while an older required 30175 constituent falls beyond it. fetchOwnerHistoryToExhaustion pages the full window with the until time cursor (the only cursor the WS REQ filter exposes; the DB before_id keyset is REST-only), deduping the inclusive-boundary rows. A short page terminates normally. A full page whose oldest event cannot advance the time-only cursor is a dense boundary — more than one page of events share one created_at second, which the WS filter has no (created_at, id) cursor to escape — and raises PersonaHistoryDenseBoundaryError rather than silently completing as if the history were exhausted and dropping the older constituents behind it.
• Constituents-before-catalog ordering. Over the complete batch, orderCatalogHeadsLast stably defers every 30178 head past its 30175/30176 constituents. Reconciling a 30178 head before its personas hydrate makes the inbound team refresh fail member resolution and queue a dominating false tombstone; deferring the heads guarantees the constituents are all applied first, while newest-wins order within every other coordinate is untouched.
• Hydration boundary for concurrent live events. The backfill fetch and the live subscription start concurrently into one reconcile chain. A live or replayed 30178 that arrives before the backfill reconciles its constituents would reproduce the same false-tombstone purge, so live events are buffered until the ordered backfill is dispatched and then drained in arrival order. Steady-state live events (after hydration completes) reconcile immediately.
• Explicit backfill failure policy. A transient history-fetch rejection is retried with bounded backoff. When backfill cannot complete — retries exhausted, or a deterministic dense boundary — the pipeline enters a degraded-live state rather than leaving the subscription permanently inert with live events accumulating in the buffer: the hydration boundary still opens so buffered and future live events keep reconciling, but the whole catalog dependency set is dropped — the 30178 head, its 30175/30176 constituents, and any kind-5 deletion carrying a dependency-targeting a tag (classified by scanning all a tags, matching the backend's deletion router, which find_maps across every tag and routes the first signer-owned coordinate — so a malformed or foreign first a tag ahead of an owned 30176 cannot slip a destructive deletion through) — because backfill never fully hydrated the owner's constituents. Dropping only the 30178 head is not enough: the backend refreshes the catalog head after every team/persona save, and live delivery is newest-first, so a 30176 edit that adds a new member would reach the backend before that member's 30175 and falsely tombstone a witness-holding device's valid team. Holding the prior hydrated run's constituents on disk only proves the old revision is resolvable — it says nothing about a new member — which is why the entire dependency set is held rather than just the head. 30177 managed-agent runtime policy stays live (it drives no catalog refresh). A degraded device stays stale on team/persona edits until it self-heals on the next effect re-run (restart, or an identity/community switch) — the correct trade against destroying valid shared state.

Data layer

Relay paging, signature verification, NIP-33 head selection, and untrusted-content parsing for the kind 30178 team catalog live natively in the fetch_team_catalog Tauri command (team_catalog.rs), structurally mirroring fetch_persona_catalog (persona_catalog.rs). A catalog refresh crosses IPC once and never verifies a signature on the webview thread. teamCatalogRelay.ts is now a thin presentation and local-linkage layer over the verified projection — it shapes entries for display and links each to a local team, and never parses or verifies.

Parsing is all-or-nothing, identical to the add-time re-fetch in add_team_from_catalog: a team with any invalid member fails to parse and the publication is dropped from the catalog, matching persona behavior. Behavior delta: the previously reviewed partial-render of invalid-member teams — a warning banner on an entry that could never be added — is removed. Invalid publications are dropped entirely rather than surfaced as un-addable.

Hooks

useTeamCatalogRelay.ts mirrors the persona catalog hook: a community-keyed query over fetch_team_catalog, live invalidation on kind 30178, share/unshare, and add-from-catalog (which invalidates both the teams and personas stores, since adopting a team copies its members as local personas).

CommunityCatalogDialog

Single unified surface replacing the former separate dialogs. Agents and Teams appear as labeled sections with type-tagged selection and a teams-preferred launch. TeamsSection's discover entry and the new-agent card both open this one dialog. PersonaCatalogDialog.tsx is removed; persona browsing now lives inside the unified dialog.

TeamShareDialog

Publishes and unshares team catalog entries via set_team_shared.

e2e + screenshots

team-catalog.spec.ts covers the browse + adopt flow; team-catalog-screenshots.spec.ts produces the pixel-regression set. e2eBridge.ts gains mockTeamCatalogPublications, which mirrors the native command's head selection and shared gate and performs only a shallow v/name/members-array shape check; per-member validation stays in the Rust command.

Follow-ups

None. The shared agent-definition text-safety policy (Unicode-control/bidi/zero-width rejection) already covers the team surface: #5112's validate_team_catalog_content chokepoint gates every field delivered verbatim to the harness on both the publish and adopt paths, and this PR's parse layer consumes that verified projection rather than re-validating on the webview thread.

[wesbillman]

Reviewing on Wes's behalf. Requesting changes for two security blockers in the catalog review surface:

1. Verify relay events before they can affect paging, coordinate selection, attribution, or displayed content. fetchCatalogEvents currently inserts every raw RelayEvent returned by the socket into byId and derives oldestCreatedAt from it; sharedCatalogHeads then trusts the raw id, pubkey, created_at, tags, and content. RelayClient.fetchEvents is only a transport fetch and does not verify signatures. A forged/unsigned 30178 event can therefore appear under another publisher, claim or retract their coordinate ahead of a valid signed head, and control the pagination cursor. The backend re-fetch and verification correctly prevents adoption, but it does not protect browsing, publisher attribution, remote image loads, or denial/shadowing of legitimate entries. Please verify ID + signature on a fresh wire-shaped object before adding an event to the paging map or deriving a cursor/head from it, and add regressions for a forged newer head, forged author/content, malformed signature, and an invalid event attempting to control until. The equivalent hardening and tests already exist in PR #4220 for kind 30175; this shared helper should preserve that invariant for both 30175 and 30178 rather than regress it.

2. Render executable team/member instructions byte-for-byte, not as Markdown, and reject non-reviewable controls at the adoption boundary. TeamCatalogDialog.tsx passes both team.instructions and member.systemPrompt through the chat Markdown renderer. Markdown can conceal spoiler bodies, link destinations, and image sources, so the instructions reviewed in the dialog can differ materially from the plaintext later executed by the adopted agents. The current team catalog validators only enforce schema/size bounds, so bidi/default-ignorable controls can also make reviewed text differ from execution. Please use the literal instruction-review component/invariant from PR #4220 and apply its executable-text validation to team instructions and every member prompt before publication/adoption. Add coverage proving Markdown syntax stays literal, hidden controls fail closed, and accepted bytes are preserved exactly through adoption.

The feature has unusually substantial coverage otherwise: this head adds/changes 62 test/spec/fixture files, including the Rust adoption/pending/sharing/reconcile suites, TS relay/parser tests, and Playwright catalog/screenshot specs. CI is green at e64aa20ff81e236ca068aab3b9ad93142fb839e3, but the existing fixtures use placeholder sig: "sig" values and therefore do not exercise the first trust boundary.

[wpfleger96]

Community Catalog — browse (teams section)

Team list with name, member count, description, and "Add team" footer.

Community Catalog — member expanded

Per-member row expanded showing Type, Preferred model/runtime/provider, and agent instruction.

Community Catalog — team instructions

Team instructions section collapsed above member rows.

Community Catalog — already added

Footer button reads "Added to my teams" (disabled) after the team is adopted.

Community Catalog — empty state

Both agents and teams empty: "Nothing shared yet" placeholder.

Community Catalog — both sections

Agents and Teams section headers both visible with one shared entry each.

Share dialog — not yet shared

Share dialog before enabling catalog access.

Share dialog — published

Share dialog with catalog toggle on and published toast.

[wesbillman]

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

One security/privacy blocker remains on this head:

Do not fetch publisher-controlled member avatars merely because someone opens the Teams catalog. team_catalog.rs projects each catalog member's remote avatar_url, and CommunityCatalogDialog.tsx automatically selects the first team on a Teams launch and immediately renders every collapsed member row through ProfileAvatar. That component assigns the URL to an image source, while mediaUrl.ts deliberately leaves external hosts unchanged. A publisher can therefore attach up to 64 unique tracking URLs to a team and learn a viewer's IP/network metadata and precise catalog-view timing as soon as the viewer opens Discover Teams. referrerPolicy="no-referrer" removes the referrer but does not prevent the request.

Please keep untrusted remote member avatars from loading during catalog browse, for example by rendering initials unless the user explicitly opts in, or by using a privacy-preserving image proxy with strict size/type/time limits. Lazy-loading only after expansion reduces the unsolicited fan-out but still exposes the viewer after an ordinary review action. Add a regression proving that opening/browsing a team does not request publisher-controlled avatar hosts.

The previously reported signature-verification and executable-text issues are addressed: verification occurs before paging/head selection, malformed or unshared newest heads suppress older entries, add-time adoption re-fetches the claimed event, and team/member instructions render literally after native concealment validation.

[wesbillman]

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

Requesting changes for two blocking defects on this head:

1. The previously reported catalog-avatar privacy leak is unchanged. team_catalog.rs still projects each publisher-controlled member.avatar_url; opening Discover Teams still auto-selects the first team; and CommunityCatalogDialog.tsx immediately renders every collapsed member row through ProfileAvatar. That component assigns external URLs to <AvatarImage src>, while rewriteRelayUrl deliberately returns non-relay origins unchanged. Merely opening the catalog can therefore request attacker-hosted images and expose the viewer’s IP/network metadata and precise browse timing. referrerPolicy="no-referrer" does not prevent the request. Please render non-network initials for untrusted catalog members, or use an approved privacy-preserving proxy only after explicit consent, and add a regression proving catalog browse makes no publisher-controlled avatar requests.

2. The catalog pager truncates permanently at a full timestamp boundary. fetch_team_catalog pages with only inclusive until; merge_verified_page advances using only the oldest verified created_at and stops when the next page adds no IDs. If 500 verified events share one second, the relay may return those same 500 for the next request; the code then declares completion, omitting every remaining event at that second and all older teams. Since the query is community-wide, one publisher can crowd older entries out with signed coordinates. Please use a tie-safe continuation strategy and cover more than one page of same-second events.

The earlier signature-verification and literal executable-text blockers remain fixed. The native add path also re-fetches and verifies the claimed head before mutation, with locked commit/rollback and retained publication retry state.

[wesbillman]

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

Requesting changes for two blocking defects that remain at this exact head:

1. The catalog still fetches publisher-controlled member avatars on browse. team_catalog.rs projects every member.avatar_url into the renderer. A Teams launch auto-selects the first team, and CommunityCatalogDialog.tsx immediately renders all collapsed member rows with ProfileAvatar avatarUrl={member.avatarUrl}. ProfileAvatar assigns that external URL to <AvatarImage src>, so merely opening Discover Teams can send requests to up to 64 attacker-controlled hosts and disclose the viewer’s IP/network metadata and precise browse timing. referrerPolicy="no-referrer" does not prevent the request. Please render non-network placeholders for untrusted catalog members, or use an approved privacy-preserving proxy after explicit consent, and add a regression proving catalog browse makes no publisher-controlled image requests.

2. The community-wide catalog pager still truncates at a full timestamp boundary. fetch_team_catalog pages with only inclusive until; merge_verified_page advances using only the oldest verified created_at and returns Done when the next page adds no IDs. With 500 verified events sharing one second, the relay can return the same 500 again, causing every remaining event at that second and all older teams to be silently omitted. The new dense-boundary failure/degraded policy exists only in usePersonaSync's owner-specific history hydration; it does not make fetch_team_catalog tie-safe. Please implement a continuation strategy that cannot claim completion at this boundary, and test more than one catalog page sharing the same timestamp.

The native verification/head-selection and literal executable-text paths remain sound on this head. Add-time adoption also re-fetches and verifies the exact shared coordinate before mutating local stores. CI is green, but the two privacy/completeness defects above remain directly reproducible from the exact-head source.

[wesbillman]

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

Requesting changes for two blocking defects that remain at this exact head:

1. The catalog still fetches publisher-controlled member avatars on browse. team_catalog.rs projects every member.avatar_url into the renderer. A Teams launch auto-selects the first team, and CommunityCatalogDialog.tsx immediately renders all collapsed member rows with ProfileAvatar avatarUrl={member.avatarUrl}. ProfileAvatar assigns the resulting external URL to <AvatarImage src>, while rewriteRelayUrl deliberately returns non-relay origins unchanged. Merely opening Discover Teams can therefore send requests to up to 64 attacker-controlled hosts and disclose the viewer’s IP/network metadata and precise browse timing. referrerPolicy="no-referrer" does not prevent the request. Please render non-network placeholders for untrusted catalog members, or use an approved privacy-preserving proxy after explicit consent, and add a regression proving catalog browse makes no publisher-controlled image requests.

2. The community-wide catalog pager still truncates at a full timestamp boundary. fetch_team_catalog pages with only inclusive until; merge_verified_page advances using only the oldest verified created_at and returns Done when the next full page adds no IDs. With 500 verified events sharing one second, the relay can return the same 500 again, causing every remaining event at that second and all older teams to be silently omitted. The dense-boundary failure/degraded policy added to usePersonaSync protects owner-specific history hydration only; it does not make this separate native catalog pager tie-safe. Please implement a continuation strategy that cannot claim completion at this boundary, and test more than one catalog page sharing the same timestamp.

The native trust/adoption path and the pending publication/cross-device lifecycle were also reviewed at this head with no additional blockers found. Exact-head CI is green, but it does not invalidate these privacy and completeness defects.