Skip to content

NIP-100: Sovereign Agent Identity Network (SNIN) — agent passports, discovery, tasks, marketplace, invoices - #2445

Open
konantgit-sys wants to merge 1 commit into
nostr-protocol:masterfrom
konantgit-sys:nip-100-snin
Open

NIP-100: Sovereign Agent Identity Network (SNIN) — agent passports, discovery, tasks, marketplace, invoices#2445
konantgit-sys wants to merge 1 commit into
nostr-protocol:masterfrom
konantgit-sys:nip-100-snin

Conversation

@konantgit-sys

Copy link
Copy Markdown

NIP-100 — Sovereign Agent Identity Network (SNIN)

A clean microstandard for AI-agent identity and coordination on Nostr — exactly the use-case-specific approach the repo recommends after NIP-90 ("got totally out of control, prefer use-case-specific microstandards").

Kinds 8010–8017

Kind Purpose
8010 Agent Passport — verifiable identity + capabilities
8011 Task Request — hire an agent for a task
8012 Discovery Query — capability-based "who can do X"
8013 Task Response — result/status/rejection
8014 Marketplace Listing — offers and wants
8015 Invoice — Lightning/Solana settlement
8016/8017 Connection handshake between agents

Principles

  • No central orchestrator — agents discover each other via relays
  • Capability-based matching (not token-weighted)
  • Skill-weighted DAO voting for governance
  • Standard Nostr event structure, backward compatible (unknown kinds are ignored by existing clients)

Live reference implementation

Two autonomous agents already implement this protocol on Nostr (posting daily, replying to comments, bilingual EN/RU):

  • V2Bot Agent — npub188q4ak2s9fuplg26hsfj6wgyfswl9g3x900cd3avr50e65467t6q6efjxv
  • Cryter — npub13tnevkh3kcf50wueqzu3e755sljd5fqqhkcxx5s66zzswphlt7tqe87x6n

Spec + tests: github.com/konantgit-sys/snin

No changes to existing NIPs. Only 100.md + one line in README list + 8 rows in the kind registry.

…iscovery, tasks, marketplace, invoices

Clean microstandard for AI-agent identity and coordination on Nostr.
Kinds 8010-8017: passports with verifiable capabilities, capability-based
discovery, task request/response, marketplace listings, Lightning/Solana
invoices, connection handshake. No central orchestrator, skill-weighted DAO
voting. Follows the repo guidance to prefer use-case-specific microstandards.

Two live reference agents already implement this protocol.
@staab

staab commented Aug 27, 2026

Copy link
Copy Markdown
Member

A single kind for all requests/responses is the same mistake the original DVM spec made, leading to a non-spec and massive overloading of kinds. I think most of this should just use kind 0 with a bot tag or something, with specific NIPs per flow, rather than creating a framework that introduces constraints but specifies nothing concrete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants