kinnet.humanmeetsai.com
The Participant Network

Does this agent really act for that organization — or that person?

Kinnet answers with signed bytes anyone can verify — self-certifying identities held by their owners, append-only key histories, and delegation chains that prove themselves offline. No registry to trust. No API key to ask for. No operator with special powers, including us.

People, organizations and AI agents as nodes joined by signed edges; one agent carries a verified badge.
Live attestation
service — commit — status asking the network… round trip —
Your browser is asking the live discovery service what build it runs. Every service reports the commit it was built from, so the deploy attests itself — the page never has to be believed.
Who it's for

Two cases, one missing primitive

Agents now act for businesses and for people. Whoever receives an agent's request needs to know who it acts for and what it may do — and whoever sends one needs a way to say so that strangers can check.

For a business

Agents are calling your API. Whose are they?

Quotes, orders, bookings, data requests — more of them arrive from agents every month. Before you act, you need to know which organization stands behind one and what it is allowed to do. And when you send agents out, you need to say the same about yours.

  • An API key proves a billing account.
  • An OAuth token proves a login to some platform.
  • An agent card advertises capabilities — unsigned, no issuer behind it.
  • Enterprise IAM stops at the tenant edge; it says nothing to a counterparty.
  • So: allowlists, shared secrets, and hope — and no way to revoke everywhere at once.

With Kinnet: the organization signs "this agent represents us and may do these things, until then". Your service verifies the whole chain offline in a few lines of middleware — revocation included, no registry to trust, no integration project per counterparty.

For a person

Your agents, your identity, your conversations — yours.

You send an agent to book, buy, negotiate, or reply for you. You want to say "this one is mine, and this is all it may do" — in a way the other side can check — instead of handing it your logins.

  • Your agent gets a full login on every platform it touches.
  • You have accounts, not an identity — each owned by a platform, none able to vouch for you elsewhere.
  • Nobody who knows you — an employer, a body, a community — can say so portably.
  • A lost phone is a lost identity, and private chat is readable in the middle.

With Kinnet: an identity that is a key you hold — rotate and recover it yourself, no account. Scoped, expiring, revocable grants to your agents and devices. Claims and relationships you carry with you. A human lane that is end-to-end encrypted (MLS), unreadable by any node operator.

The root cause is the same. Nothing on today's internet lets the represented party — a company or a person — state who acts for it and what they may do, in a form a stranger can verify from bytes and the issuer can withdraw. That is the primitive the Participant Network supplies.

Try the live network

Four steps, no signup

The directory below is real, running, and open to read. Three participants live on it — HumanMeetsAI, its founder An Lu (who holds his own key), and the operator agent HumanMeetsAI runs — and everything about them is a signed record you can verify yourself.

1 · Prove the build

Ask discovery what it's running and compare the commit against the release tag.

curl -s https://discovery.kinnet.humanmeetsai.com/version

2 · Read real records

HumanMeetsAI's signed profile, then what it says about its founder — a member-of edge and a role claim, over its own signature.

curl -s https://discovery.kinnet.humanmeetsai.com/participants/pk_zQmY3jDEWRfTnaEmRg773xoVieVabRDG1cvFabnr7uYrvip
curl -s https://discovery.kinnet.humanmeetsai.com/participants/pk_zQmTDqHZKz4CyiPYoKFfspD2Y1FFPdWPKEJmWSJqntjbd2j/relationships

3 · Verify it from bytes

Replay the key log, check the id derives from it, verify every record against the key of whoever issued it — locally, trusting no one. Add --tamper to watch one flipped byte fail.

npx @kinnet/verify pk_zQmTDqHZKz4CyiPYoKFfspD2Y1FFPdWPKEJmWSJqntjbd2j
# or, from a checkout: pnpm exec tsx examples/verify.mts <id>
# ✔ derives from its inception keys · ✔ profile signed by the current key
# ✔ member-of, issued by HumanMeetsAI (signature valid)

4 · Mint your own

Generate keys locally, publish your inception record, verify yourself with the same script. Self-custodial — the keys never leave your machine.

npm install @kinnet/crypto @kinnet/discovery-client   # then the me.mts snippet from the README
npx tsx me.mts
# → pk_zQm…  (that's you)
npx @kinnet/verify pk_zQm…
How it holds together

Identity is a key, not an account

Discovery public records only · a cache Organization or person ParticipantId · key log Agent ParticipantId · key log Your service @kinnet/verify Relationship: represents Grant: scoped · expiring Revocation, by digest publish logs · edges · grants · revocations signed request HTTPS · RFC 9421 replay key log · verify signature walk represents + grant chains check expiry + revocation — all locally → verified: represents · abilities or 401 + reason Nothing calls the organization at request time. Discovery can withhold or delay a record — it cannot forge one, or bind an id to a key its holder never signed. Run your own, use anyone's, or cache one: same guarantees.
One request, verified from bytes. The represented party issues three kinds of record; discovery only carries them; the verifier does every check itself. A dashed edge is data at rest, a solid edge is a signature, the blue edge is the request.

Self-certifying identity

A participant — human, organization, service, or agent — is a public key with an append-only key-event log. The ID derives from the inception keys, rotation is pre-committed, and recovery needs no one's permission. There is no signup and no issuer to impersonate.

Delegation that proves itself

"This agent represents that organization — or that person — and may do these things" is a chain of signed grants presented alongside each request. Any service verifies the whole chain offline against the key logs — capabilities are presented, never registered, so there is no grant database to breach or subpoena.

Public records, private conversations

Discovery stores only what is meant to be public: identities, keys, routing, verification records. Messages live on participant nodes, and the private lane is end-to-end encrypted (MLS) — the node relays bytes it cannot read.

PUBLIC · DISCOVERY Discovery a directory, not a trusted party identities · keys · routing hints · claims · relationships · grants · revocations anyone reads only the key holder writes (signed request) PRIVATE · PARTICIPANT NODES Alice Alice's node messages · conversations · files Bob Bob's node messages · conversations · files machine lane — authenticated plaintext human lane — end-to-end encrypted (MLS) the nodes relay bytes they cannot read
Public records, private conversations. Discovery never sees a message; a node never gets to read the human lane. Losing or adding a device is a key-log event on the public side and an MLS membership change on the private side — nothing else moves.
Protocol · implementation · network

Built to be implemented by strangers

The Participant Network

The protocol: numbered specs plus committed conformance vectors (pn on the wire). Two implementations that accept and reject the same vectors interoperate by construction.

Kinnet

The reference implementation — the packages, specs, and vectors in the open-source repository (Apache-2.0).

The network

Whoever runs it. This directory is a convenience anyone can host; every guarantee a verifier relies on is checked from signed bytes, not from trusting an operator.