RFC: Cross-community agent marketplace (discovery + install) built on the shared-persona catalog and buzz://install-agent

[adamazad]

Summary

Buzz has rich intra-community agent primitives but no cross-community discovery or install path. A user who wants an agent (a coding harness, a triage bot, a design agent) has no way to find one built by someone else and install it into their own community. This RFC proposes a minimal, Nostr-native agent marketplace: a publisher-authored Agent Listing event kind that any client can browse/search across relays, whose install action is the owner-reviewed buzz://install-agent deep-link (#2911). Nothing auto-admits — install always terminates in the existing owner-review flow.

Motivation

Today agents are discoverable and installable only inside a community you already belong to, and only by the owner who provisions them:

• kind:10100 KIND_AGENT_PROFILE — per-agent metadata + owner ref (replaceable).
• kind:30175 KIND_PERSONA (NIP-AP) — owner-authored persona definitions; the ["shared","true"] tag already enables an opt-in, community-wide agent catalog ({kinds:[30175]} all-authors). This is a per-community catalog.
• Relay agent directory — kind:10100 RelayAgents with respond_to: anyone/allowlist build mentionableAgentPubkeys (currently gated/buggy, see Desktop: shared relay agents owned by other members are un-mentionable and un-addable (managed-list gate precedes directory eligibility) #2603).
• Provisioning — buzz agents draft-create (NIP-AO) → owner review in Desktop.

All of the above assume the agent already lives in your relay. There is no answer to:

"I run community X. I heard there's a great triage agent built for community Y. How do I discover it and install it into X?"

The persona catalog is the right shape — but scoped to one relay. A marketplace is that catalog generalized across communities, plus a standardized install action. This also directly serves #2754 (stable extension points for downstream distributions): a marketplace is the canonical distribution surface, and third parties (e.g. Figura, an on-brand design agent) become first-class listings instead of out-of-band install docs.

Proposal

1. Agent Listing event (new kind)

A parameterized-replaceable, publisher-authored event — the marketplace entry for one installable agent.

• d tag = stable listing slug (so republish replaces, per NIP-01 replaceable rules).
• Content = JSON manifest:

{
  "name": "Figura",
  "tagline": "On-brand UI mocks, posted back in-thread as a link.",
  "description": "…markdown…",
  "category": "design",              // freeform + a small recommended set
  "icon_url": "https://…",           // or a blossom ref
  "publisher": "<npub of publisher>",
  "homepage": "https://figura.so",
  "install": {
    "type": "external-daemon",       // or "managed" (Buzz-hosted runtime)
    "deeplink": "buzz://install-agent?relay={community_relay}&npub={agent_npub}&name=Figura&system_prompt=…",
    "agent_npub": "npub1…",          // for external-daemon: the identity to admit
    "persona_ref": "30175:<pubkey>:<slug>"  // for managed: the shared persona to clone
  },
  "capabilities": ["fig", "issue-triage"],
  "source": "https://github.com/…"    // optional, for trust
}

Two install shapes, both ending in owner review:

• external-daemon (own keypair, e.g. our figura buzz agent): install = admit agent_npub as a member. The buzz://install-agent deep-link (feat(deep-link): add buzz://install-agent prefill arm #2911) prefills the owner's create/admit form with relay = the installer's own community and the listing's npub/name/prompt. Owner reviews + saves. No auto-admit.
• managed (Buzz-hosted runtime): install = clone the referenced shared 30175 persona into the installer's community via the existing draft-create review. The deep-link prefills the create-agent form from persona_ref.

The installer substitutes their own {community_relay} into the deep-link — the listing is community-agnostic; the user picks where it lands.

2. Discovery

A marketplace is just REQ {kinds:[<listing kind>]} against a discovery relay (or set of them), rendered as a browse/search grid — exactly like the existing shared-persona catalog query, but cross-community. Clients already know this pattern.

Open question below on where the index lives (a canonical discovery relay vs. federated fan-out).

3. Install = existing owner-review, unchanged

Critically, the marketplace adds discovery only. The install action reuses buzz://install-agent (#2911) → Desktop create/admit form → owner reviews and saves. The marketplace never grants membership, never signs on the owner's behalf, never bypasses the gate. Spam/abuse blast radius on install is therefore zero — a listing is an advertisement, not a capability.

Non-goals / out of scope (for v1)

• Payments / zaps for paid agents (natural follow-up given Nostr zaps, but not v1).
• Ratings/reviews (could be NIP-25 reactions / labels later).
• Automatic updates of installed agents.

Open questions

1. Index location. One canonical discovery relay (marketplace.buzz.xyz?) that listings publish to, vs. federated (publish to your own relay + NIP-65-style fan-out, clients aggregate). Federated is more sovereign but harder to browse comprehensively.
2. Kind number. New replaceable/parameterized-replaceable kind in the Buzz custom range — or extend 30175 with a ["marketplace","true"] tag and a cross-relay publish convention (reuses all the shared-catalog machinery). The latter may be the smaller change.
3. Trust / verification. How does a browser trust a listing's agent_npub and source? Publisher attestation (NIP-05?), signed source provenance, or a curated allowlist for a "verified" badge.
4. Moderation. Spam listings → NIP-56 reports + relay-side policy? Who curates the canonical index if one exists.
5. Relationship to Desktop: shared relay agents owned by other members are un-mentionable and un-addable (managed-list gate precedes directory eligibility) #2603. Should the intra-community directory (kind:10100) and the cross-community marketplace share a rendering surface in Desktop, or stay distinct (installed vs. installable)?

Prior art in this repo

• RFC: Stable extension points for downstream integrations and distributions #2754 — RFC: stable extension points for downstream integrations and distributions (a marketplace is the distribution surface this asks for).
• Desktop: shared relay agents owned by other members are un-mentionable and un-addable (managed-list gate precedes directory eligibility) #2603 — relay agent directory eligibility (intra-community discovery, currently gated).
• feat(deep-link): add buzz://install-agent prefill arm #2911 — buzz://install-agent deep-link (the install action this RFC builds on). Already open, tests green.
• NIP-AP (kind 30175) shared-persona catalog — the per-community precedent this generalizes.
• NIP-AO — owner-review agent provisioning (the security model install preserves).

Why now

We (Figura) just shipped an external Buzz agent (own daemon + keypair, link-only in-thread figs) and the #2911 deep-link. We have a concrete, non-hypothetical first listing and are willing to prototype the Listing kind + a Desktop browse surface against whichever direction the maintainers prefer on the open questions. Filing this to find out if a marketplace is wanted upstream before we build it as a fork-only distribution.