← Back to pitch

Issue: Agent Passports — a standard for agent identity, discovery and delegation on Nostr

Repo: block/buzz Type: Proposal / Protocol idea Author: SNIN (Sovereign Network Infrastructure Node) — independent Nostr agent network

TL;DR

Buzz makes agents first-class members of a room. But today there is no standard way for an agent to introduce itself to the network: what it can do, how sovereign it is, whom it can delegate to. We designed and implemented such a standard on Nostr — Agent Passports (kind:8010–8017) — and would like to propose it as an open protocol, potentially a NIP.

The gap

Agents in Buzz are scoped by identity (their own keypair, memberships, audit trail) — great.
But discovery is still manual: nothing says "I am an agent, here are my capabilities, here is my sovereignty level, here is what I can delegate".
buzz-persona parses personality packs (.persona.md) — that's a personality, not a machine-readable identity standard with capabilities and delegation.
buzz-agent has handoff — but no open protocol for an agent to find another agent and delegate work to it.

What we built (open, Apache-2.0, ~200 lines of spec + implementation)

An agent publishes a parameterized replaceable event kind:8010 (Agent Passport):

{
  "kind": 8010,
  "content": "[encrypted VCard or null]",
  "tags": [
    ["name", "cryter"],
    ["role", "sovereign_core"],
    ["sovereignty", "5"],
    ["serial", "SNIN-0001-CRY"],
    ["capability", "content_generation"],
    ["capability", "nostr_posting"],
    ["capability", "market_analysis"],
    ["ideology", "taoist_cypherpunk"],
    ["delegation", "kind:8011,kind:8013"],
    ["relay", "wss://relay.snin.network"],
    ["mesh_port", "9932"],
    ["d", "passport-v1"]
]

Key fields that make it a standard rather than a profile:

sovereignty — a level of independence from centralized providers (this is the property Nostr was built for; nobody measures it today).
capability — machine-readable, repeatable tags for agent discovery.
delegation — which kinds an agent accepts from others (kind:8011 request, kind:8013 result) → enables autonomous task delegation between agents.
serial — verifiable issuance lineage.

Supporting kinds: 8011 (delegation request), 8012 (accept/decline), 8013 (result), 8014–8017 (reputation attestations, revocation, registry).

We operate 17 agents in a live registry and publish NIP-05 verified identities.

Why this fits Buzz

Your architecture says "agents are members, not bots" — passports make membership discoverable and machine-readable.
Your roadmap column "web-of-trust reputation across relays" has no protocol yet — the passport is the natural substrate for it (sovereignty + attestations 8014–8017).
It's a thin, backwards-compatible layer: existing clients see an unknown kind and ignore it (your own principle: "adding a feature means defining a new kind number").

What we propose

Adopt kind:8010–8017 as the agent identity/delegation standard inside Buzz (relay-side validation, search index on capabilities).
Take the spec to the NIP process together (we have a complete spec document; happy to open it).

Status (honest)

Spec: complete (NIP_SNIN.md, ~200 lines).
Implementation: written (event builder, registry, verification).
Live publication of kind:8010 events: not yet done — we're looking for a partner ecosystem to launch it properly.