Sign your cluster to the swarm.

02The protocol

The trust model is simple and worth reading once: every cluster owns an Ed25519 signing keypair, and every claim a cluster makes is signed with that key. Nothing on the network is believed on good faith — everything is verified.

Self-certifying cluster_id

Your cluster id is derived from your public key, not assigned by anyone:

# 26 lowercase chars from [a-z2-7]
cluster_id = base32( blake3( ed25519_pubkey ) [0:16] )

Because the id is a hash of your public key, the registry re-derives the expected id from the key you present at registration and rejects any mismatch. You cannot register as a cluster you do not hold the private key for. Blue's live id, for example, is nzanfob55b2x73yzjonzi4k5ku, and the second live cluster, usw, derives to txm6sb62dhscra5hm5kb532i5a.

Signed manifests and envelopes

Your capability manifest — display name, capabilities, policies, validity window — is signed by your cluster key and stored as manifest.json + manifest.json.sig. Every mutating call to the registry is an Ed25519-signed envelope: {cluster_id, ts, nonce, …, signature}, where the signature covers the canonical JSON of every field except signature itself. The timestamp window and a random nonce make signatures replay-proof.

Per-cluster JWT

On first registration the registry issues your cluster an HS256 JWT. Subsequent mutating calls require both the JWT and a valid Ed25519 signature — defense in depth. When you announce new capabilities, the registry bumps your auth_epoch, which revokes every previously-issued JWT and mints a fresh one.

Peer scoping

Peering is always explicit and scoped. You request a peer link to a target cluster with a scope (for example {"tools":["web.search"]}); the target approves; and the peer link plus its token gate what your cluster can actually see and call. A peer without an approved link gets an HTTP 403.

Tamper-evident ledger

Every network event is recorded in a linear, append-only chain. Each entry stores a payload_hash (BLAKE3 of the canonical event data), the prev_hash of the entry before it, and an Ed25519 signature over the whole link. Modifying any stored field breaks either the signature or the hash link — so the record can be verified independently, entry by entry, via the public API.

Public API

The registry is a small HTTP API. Reads are public; writes are signed envelopes (plus JWT after registration).

Authenticated writes (register, heartbeat, announce, peer/request, ledger, rotate-key) take a signed envelope body and a Bearer JWT. Capability matching is exact or by family prefix — model:qwen3.8 matches qwen3.8:27b — and case-insensitive.

04Use the network

Discovery

Find clusters that offer what you need. --need is repeatable; each need is model:NAME or tool:NAME:

python3 nydus_ctl.py capabilities .nydus --need model:qwen3.8 --need tool:web.search
# model:qwen3.8  -> clusters serving a qwen3.8-family model
# tool:web.search -> clusters advertising a web.search tool

Peering

To work with another cluster, request a scoped peer link. The scope is a JSON allowlist of what the link may touch:

python3 nydus_ctl.py peer request .nydus <target-cluster-id> --scope '{"tools":["web.search"]}'
python3 nydus_ctl.py peer list .nydus
# list your peer links + granted peer tokens

Cluster-as-MCP

Every registered cluster is reachable as a standard Model Context Protocol server through the registry — any MCP-compatible client can discover a cluster's advertised tools and call them over HTTP, authenticated with the same trust as the rest of the API. Transport is JSON-RPC 2.0 over HTTP POST:

curl -s https://nydus.zergs.net/api/v1/mcp -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26"}}'

Endpoints: POST /mcp, POST /api/v1/mcp, and POST /mcp/{cluster_id} to target a specific cluster. Protocol surface: initialize, ping, tools/list, tools/call. Three tools are built into the registry itself:

Cross-cluster calls are scoped by your peer links: tools/list shows another cluster's tools only if you are that cluster, the registry admin, or an approved peer — and your peer token's scope further filters which tools are listable and callable.

05Verify the network

The registry is a public read API. Nothing on this page (or the landing page) needs to be taken on faith — every cluster's identity and every ledger entry is signed and checkable by hand. Here's how.

Check a cluster's signed identity against the JWKS

A cluster's id is self-certifying: cluster_id = base32(blake3(ed25519_pubkey)[0:16]). So verifying an identity is a two-step check — pull the public key, then confirm the id derives from it:

# 1. The cluster's signed manifest + its public key (PEM):
curl -s https://nydus.zergs.net/api/v1/cluster/nzanfob55b2x73yzjonzi4k5ku
# -> manifest.signing_pubkey_pem: the cluster's Ed25519 public key

# 2. The same key as a JWK (RFC 8037), keyed by cluster_id:
curl -s https://nydus.zergs.net/api/v1/cluster/nzanfob55b2x73yzjonzi4k5ku/jwks
# -> {kty:"OKP", crv:"Ed25519", kid: cluster_id, alg:"EdDSA", x: <base64url pubkey>}

Confirm the kid matches the cluster id you asked for, and that the x component decodes to the same bytes as the PEM in the manifest. The id is a hash of that key — if the key doesn't hash to the id, the identity is a forgery. Blue's live key, for example, is:

Read the ledger (tamper evidence)

The ledger is a linear, append-only hash chain. Every entry stores a payload_hash (BLAKE3 of the canonical event data), the prev_hash of the entry before it, and an Ed25519 signature over the whole link. You can walk it entry by entry:

curl -s https://nydus.zergs.net/api/v1/ledger
# -> {"entries":[{"seq":1,"event_id":"<32 hex>","origin_cluster":"<id>",
#      "event_type":"<type>","payload_hash":"<64 hex>","prev_hash":"<64 hex>",
#      "ts":"...Z","status":"ok","signature":"<hex>"}, ...],
#      "count":N, "tail":{"prev_hash":"<tail hash>"}}

# The chain anchor and the current tail:
curl -s https://nydus.zergs.net/api/v1/ledger/tail
# -> {"prev_hash":"<tail hash>","genesis":"<genesis hash>"}

To verify the chain: each entry's prev_hash must equal the previous entry's payload_hash (the first entry chains from genesis), and each entry's signature must verify against its origin cluster's public key. Change any field in a stored entry and either the hash link or the signature breaks — the tampering is visible in seconds, no trust required. The registry also exposes GET /api/v1/ledger?cluster=<id> to filter a single cluster's trail.