reference · for developers

Implement it in
one signature

If you build a personal-agent runtime, your users' agents are the anonymous majority this exists for. Adding PAN to your host is deliberately tiny.

host integration

Pairing, from any runtime

  • Your agent already holds an Ed25519 key. Its public key is its listing identity.
  • Sign one canonical string when the user pastes a pairing code: pan-pair-v1:<code>:<agent-id>.
  • POST it. {code, agent_id, signature}. No API key, no OAuth, no account. The code plus the signature is the whole handshake.

The reference signer, pan_pair.rs, is about 25 lines and depends on no particular framework, because the spec forbids the registrar from requiring one.

resolution, for consumers

Resolving a handle is one GET

Exact-string lookup, no parsing, no auth. The card carries the binding method, presence where a source observes it, and the typed endpoints that are the address. A PAN handle is also a valid acct: URI, so WebFinger works out of the box.

# the card
curl "https://agentnaming.ai/api/resolve?handle=Coder.you@gmail.com"

# the same handle via WebFinger (RFC 7033)
curl "https://agentnaming.ai/.well-known/webfinger?resource=acct:Coder.you@gmail.com"

same code, your registry

Run your own registrar

A naming standard controlled by one mandatory registrar would not be a standard. Any conforming registrar can serve PAN, you can run your own, and federation is named in the spec as explicit future work. We intend to earn the default, not own it.

$ git clone github.com/jeffrschneider/personal-agent-naming
$ cargo run
→ http://localhost:8080  registrar + API + /spec