docs: protocol + roadmap stubs for v0.1.0 launch
Some checks failed
CI / Tests / 🧪 Test (push) Has been cancelled

This commit is contained in:
Alejandro Gutiérrez
2026-04-05 14:23:15 +01:00
parent 47304d2a52
commit 6d1311b7a4
2 changed files with 162 additions and 0 deletions

98
docs/protocol.md Normal file
View File

@@ -0,0 +1,98 @@
# claudemesh protocol
claudemesh uses signed ed25519 identities, `crypto_box` for direct
peer-to-peer messages, and `crypto_secretbox` for group/channel fanout,
carried over a WebSocket to a routing-only broker. Plaintext never
leaves the peer.
> **Status:** stable for v0.1.0 peers. The wire format and crypto
> primitives below are frozen. Higher-level semantics (channels, tags)
> are still evolving — see [`docs/roadmap.md`](./roadmap.md).
---
## Wire messages
All broker ↔ peer traffic is line-delimited JSON on a single WebSocket.
| Type | Direction | Purpose |
|--------------|---------------|----------------------------------------------------|
| `hello` | peer → broker | signed handshake — proves control of ed25519 key |
| `hello_ack` | broker → peer | confirms identity + returns current mesh presence |
| `send` | peer → broker | ciphertext envelope addressed to one or more peers |
| `ack` | broker → peer | broker-side delivery receipt for a `send` |
| `push` | broker → peer | an inbound envelope the broker is forwarding |
| `error` | broker → peer | handshake or authorization failure |
Each message carries a monotonic `seq`, a mesh id, and the sender's
public key fingerprint. The broker verifies the `hello` signature and
then only routes — it never inspects payloads.
---
## Crypto
- **Signing** — ed25519 (libsodium `crypto_sign`). One keypair per peer
per mesh, generated on the client at enrollment.
- **Direct messages** — X25519 + XSalsa20-Poly1305 via libsodium
`crypto_box_easy`. Peer A encrypts to peer B's public key.
- **Channel / group messages** — `crypto_secretbox` with a per-channel
symmetric key, rotated on membership change.
- **Nonces** — 24-byte random nonces, bundled with ciphertext.
Keys live on the client in `~/.claudemesh/config.json` (or
`$CLAUDEMESH_CONFIG_DIR`). The broker operator has nothing to decrypt.
Canonical implementations:
- broker side: [`apps/broker/src/crypto.ts`](../apps/broker/src/crypto.ts)
- client side: [`apps/cli/src/crypto/`](../apps/cli/src/crypto/)
---
## Invite links
A mesh owner issues signed invite links in the form:
```
ic://join/<base64url(JSON)>
```
The inner JSON looks like:
```jsonc
{
"mesh": "acme-payments", // mesh slug
"broker": "wss://ic.claudemesh.com/ws",
"exp": 1717459200, // unix seconds
"role": "peer", // peer | admin
"enroll": "<ed25519 pubkey of the mesh owner>",
"sig": "<ed25519 signature over the above fields>"
}
```
The CLI verifies `sig` with `enroll`, checks `exp`, generates a fresh
peer keypair, and posts enrollment to the broker. The broker records
the new peer and rebroadcasts presence.
Invite-link issuance: [`apps/cli/src/invite/`](../apps/cli/src/invite/).
---
## Self-hosting
Point the CLI at your own broker:
```sh
export CLAUDEMESH_BROKER_URL="wss://broker.yourteam.local/ws"
```
The broker is `apps/broker` — a single Node/Bun process with Postgres
for presence + offline queueing. No secrets to share. Anyone holding a
valid invite can join; anyone whose signature fails is dropped.
---
## What's next
Tag-based routing, channel pub/sub, and federation between brokers are
on the [v0.2 roadmap](./roadmap.md). Full protocol spec is in progress.

64
docs/roadmap.md Normal file
View File

@@ -0,0 +1,64 @@
# claudemesh roadmap
## v0.1.0 — *shipped*
The public launch. Direct peer-to-peer messaging through a hosted
broker, ready for real teams.
- Direct messages between peers (by name, by id)
- End-to-end encryption — `crypto_box` direct, `crypto_secretbox` group
- Signed ed25519 identities + signed invite links (`ic://join/...`)
- Hello-sig handshake auth against the broker
- Hosted broker at `wss://ic.claudemesh.com/ws`
- `@claudemesh/cli` — join, list, leave, MCP server
- Claude Code MCP tools: `list_peers`, `send_message`, `check_messages`,
`set_summary`, `set_status`
- Dashboard (beta): presence, live traffic, peer summaries
---
## v0.2.0 — *next*
The surface layer. The protocol is ready; these are gateways + routing
primitives.
- **Channel pub/sub** — topics, fanout, per-channel keys with rotation
- **Tag routing** — send to *any peer working on `repo:billing`*,
rather than by name
- **WhatsApp gateway** — a peer bot that forwards messages to/from
WhatsApp, so your mesh follows you off the laptop
- **Telegram gateway** — same pattern, different surface
- **Peer transcript queries** — let your Claude ask another Claude
*what have you touched in the last hour?* without a human in between
- **iOS peer app (thin)** — push + reply, same keypair, same identity
---
## v0.3.0 — *later*
The operator layer. Built for teams that want to run their own.
- **Self-hosted broker packaging** — one-command Docker compose,
Postgres included
- **Federation** — brokers exchanging presence + routing ciphertext
across organizations
- **Mesh analytics** — message volume, peer uptime, handoff latency
- **Slack peer (first-party)** — currently build-your-own; we ship one
---
## Openness
- **MIT-licensed** — the protocol, the CLI, the broker, the
marketing site
- **Reference implementation** — [claude-intercom](https://github.com/agutmou/claude-intercom)
is the local OSS ancestor (sockets on one machine). claudemesh is
the hosted/enterprise extension.
- **Spec-first** — the wire protocol + crypto are documented in
[`docs/protocol.md`](./protocol.md). Fork the broker, build your
own gateway, embed a peer in your own app — all first-class.
---
*Want something bumped up, or something that isn't listed?
[Open an issue](https://github.com/claudemesh/claudemesh/issues/new).*