Building on SendWyrd.

A protocol with a public REST API. No accounts, no API keys, no gatekeepers. Sign your own wyrds; the host stays blind.

What ships today

  • REST API at sendwyrd.com/api/v1/* — publish, fetch, burn, replies, presence-check. No auth tokens; per-wyrd Schnorr signatures gate destructive ops.
  • Wire spec — byte-for-byte description of every endpoint, envelope layout, signed payload, and error code. Currently at v1.0.4-draft. The published @sendwyrd/core package is the executable reference — npm view @sendwyrd/core or unpack the tarball to read the implementation directly. The companion spec doc is available on request from @deltaclimbs.
  • Reference TS package @sendwyrd/core — compose/decrypt envelope, HD derivation, URL parsing, ECIES replies, Schnorr sign/verify. ~1.6k LOC, 96% unit-test coverage. On npm: pnpm add @sendwyrd/core. v0.1.x unstable; semver from v1.0.0.
  • MCP server — @sendwyrd/mcp on npm, stdio, exposes the wyrd verbs to MCP-capable clients (Claude Code, Claude Desktop, Cursor, Zed). Install with npx -y @sendwyrd/mcp.

For builders

The wire is plain HTTP + JSON. No accounts, no API keys. Every destructive operation is gated by a per-wyrd Schnorr signature from K_origin_priv; every read is open to anyone holding the URL fragment containing K_read.

To publish: derive a K_origin keypair, generate a random 32-byte K_read, AES-256-GCM-encrypt the body with the AAD bound to handle/expiry/reply-mode, Schnorr-sign thepublish_message, POST. The reference TS module shows the full pipeline in ~50 lines.

If you're in JS/TS: install @sendwyrd/core via npm i @sendwyrd/core (or pnpm add) for composeWyrd, decryptFromBase64Url, deriveOriginKey, buildFragmentUrl, and parseWyrdUrl. v0.1.x is unstable; semver discipline starts at v1.0.0.

If you're in another language: the spec is implementable from primitives in any language with secp256k1 + BIP-32 + AES-256-GCM. The Schnorr signatures are BIP-340; the HD derivation is BIP-32 hardened; the seed format is BIP-39. All standard.

For agents

An agent is just a client. There is no “agent” primitive in the protocol — agents publish wyrds with their own seeds, derive their own per-wyrd K_origin keys, and are indistinguishable from any other composer at the wire. This is by design: identity is not the protocol's concern.

If your agent runs in an MCP-capable client, the official server is the path of least resistance. @sendwyrd/mcp ships 13 verbs over stdio: compose / view / burn / reply / attest as the wyrd verbs, init / unlock / lock / forget / status for seed lifecycle, history / inbox / recover for local state. Drop the snippet below into ~/.claude.json (or the equivalent config for Claude Desktop, Cursor, Zed) and the tools appear in the model's tool list on restart.

{
  "mcpServers": {
    "sendwyrd": {
      "command": "npx",
      "args": ["-y", "@sendwyrd/mcp"]
    }
  }
}

Verbs only. No subscriptions, no polling tools, no auto-reply — that would push SendWyrd toward the conversation-hosting layer it was designed to refuse.

What's natively well-suited to agents:

  • Composing intro requests and routing them through trust networks (the use case in the manifesto).
  • Reading shared URLs an agent receives from a human (or another agent) and acting on the body.
  • Serving as the back-channel for replies: an agent can hold itsK_origin_priv and accept ECIES replies routed through the wyrd's URL.
  • Inter-agent capability handoff: pass a wyrd URL between agents the same way you'd pass it between humans.

What's deliberately NOT supported: long-lived agent identities, account/key rotation tracking, or any host-side primitive that lets one agent enumerate another agent's wyrds. The protocol's mosaic quality applies to agents the same as humans.

Endpoints

  • POST /api/v1/wyrds — publish a wyrd
  • GET /api/v1/wyrds/{object_handle} — fetch the encrypted envelope (decrypt client-side with K_read)
  • DELETE /api/v1/wyrds/{object_handle} — burn (Schnorr-signed)
  • POST /api/v1/wyrds/{object_handle}/replies — submit a reply (ECIES-encrypted to K_origin_pub)
  • GET /api/v1/wyrds/{object_handle}/replies — fetch replies (Schnorr-signed query)
  • GET /api/v1/authors/{K_origin_pub_b64u}/handles — presence-check for HD recovery sweep
  • GET /api/v1/health — liveness probe

Every endpoint returns JSON. Every binary value is base64url without padding. Every error has a structured code (see spec §17).

Roadmap

What's deliberately deferred (with no current ETA):

  • OpenAPI / JSON Schema generated from the wire spec for cross-language client codegen.
  • Python client SDK for the AI/agent ecosystem.

Anti-roadmap (will not ship; would violate VISION):

  • Server-side compose endpoint that takes plaintext (host-blindness violation).
  • API keys, accounts, agent identities (capability-over-identity violation).
  • Webhooks / push notifications (ADR-010: zero notification primitive at the protocol layer).
Compose a wyrd
compose