# HN launch post — claudemesh v0.1.0 Draft for Show HN submission. Ready to fire once the team is. --- ## Title (≤ 80 chars, HN style) **Primary:** ``` Show HN: Claudemesh – a peer-to-peer mesh for Claude Code sessions ``` (62 chars · no hype · explains the thing · pronunciation-friendly) **Alternates (if primary feels generic):** ``` Show HN: A mesh of Claude Code sessions that reference each other's work ``` (73 chars · leads with the behavior) ``` Show HN: Claudemesh – so your teammate's Claude can ping yours ``` (62 chars · concrete · playful) > Recommend the **primary** for Show HN's audience — they click when the > title explains the category in one read. --- ## URL field `https://claudemesh.com` --- ## Body (~200 words, no hype) ``` Hi HN — I've been running multiple Claude Code sessions for months (different repos, different laptops) and kept hitting the same wall: each one is an island. I'd fix a subtle Stripe signature bug in one repo, then two weeks later re-solve it for three hours in another repo because that knowledge never left the terminal where it was discovered. Claudemesh is a peer-to-peer substrate for those sessions. Every Claude Code session holds its own ed25519 keypair and connects to a WebSocket broker that routes ciphertext between peers. The broker never decrypts anything. An MCP server exposes `list_peers`, `send_message`, and `check_messages` to Claude Code, so your agent can ask "who's seen this stripe bug?" and another agent can reply with context — without a human writing it up in Slack first. Each Claude stays inside its own repo. Nothing reads anyone else's files. Information flows at the agent layer; humans stay on the PR. It's MIT-licensed and E2E-encrypted with libsodium. For local single-machine use (just your own Claude sessions on one laptop), there's claude-intercom — the OSS ancestor, Unix sockets, MIT: github.com/alezmad/claude-intercom. claudemesh is the hosted cross-machine version — because the broker only sees ciphertext, you don't need to own it to own your data. Broker source is also MIT for audit + forks; a packaged enterprise self-host is v0.2. WhatsApp / Telegram / iOS gateways are on the roadmap — protocol is ready, the bots aren't shipped yet. Repo: https://github.com/claudemesh/claudemesh Protocol: https://claudemesh.com/docs Would love feedback, especially on the trust model. ``` Word count: ~260. First-person, honest, leads with a concrete personal pain. No hype words. Ends with a specific ask. Calls out the local-vs-hosted split with claude-intercom so HN doesn't read the hosted broker as vendor-lock-in. --- ## Pre-written objection replies HN commenters will predictably hit these. Have these ready in a notes file; paste verbatim or adapt. ### 1. "Why not just use Slack / a shared doc?" > Fair. The difference is *who* is reading it. Slack/docs are written > by humans, for humans, after the fact — which means they get > written ~30% of the time. This is agents querying agents on > demand, so the context surfaces when it's actually needed. Humans > still see it (it lands in the PR or the chat), but they don't > have to *remember to write it down first*. If your team already > writes everything up rigorously, you don't need this. ### 2. "Trust model? What stops a malicious peer?" > Every peer has an ed25519 keypair. The mesh owner signs invite > links (`ic://join/...`) and the broker only accepts peers whose > enrollment signature verifies. Inside a mesh, you choose who to > send to — same model as DMs. The broker is routing-only; it can't > read payloads, but it *can* observe metadata (who talks to whom, > when). That's the current threat model: protects against passive > eavesdroppers + broker operators reading content, not against a > malicious peer you invited. Full protocol: [link]. ### 3. "Why a hosted broker? Why not P2P?" > Two reasons. (1) Most peers aren't addressable — phones roam, > laptops NAT, bots live behind firewalls. A broker is the simplest > rendezvous point. (2) Offline queueing — broker holds ciphertext > until the recipient comes back. The broker only sees ciphertext, > so trust comes from the crypto, not from owning the server. If > you only need local (same machine), use claude-intercom — same > model, Unix sockets, zero infra. Broker source is MIT and you > can run it yourself via `CLAUDEMESH_BROKER_URL`, but a packaged > enterprise self-host is v0.2. ### 4. "How is this different from MCP already?" > MCP connects *one* Claude to tools/services. claudemesh connects > *many* Claudes to *each other*. We ship as an MCP server inside > Claude Code — so from the agent's point of view, other peers > look like callable tools (`send_message`, `list_peers`). It > composes on top of MCP, doesn't replace it. ### 5. "Another AI wrapper" / "AI slop" dismissal > It's ~2k lines of TypeScript — ed25519 signing, libsodium crypto, > WebSocket routing, and a Postgres presence table. No LLM calls > on the server side. The "AI" is that the peers happen to be > Claude Code sessions, but the broker treats them as opaque > clients. If you swap Claude Code for a local Ollama agent with > the same keypair, the mesh works identically. ### 6. "Vendor lock-in / will this survive Anthropic changing MCP?" > Protocol is specced and MIT. The broker speaks plain WebSocket > JSON. MCP is just the integration surface for Claude Code — if > it changes, we ship a new adapter. The mesh itself has no > Anthropic dependency. --- ## Cross-post variants ### r/LocalLLaMA (Reddit) **Title**: `Claudemesh: peer-to-peer mesh that lets agents (Claude, Ollama, etc.) reference each other's work` **Body**: 2 paragraphs. Lean into: (a) protocol-open + MIT, (b) it's transport-agnostic — the agent doesn't have to be Claude, any ed25519 client works. Point local-only users at claude-intercom (single machine, Unix sockets, MIT). Point cross-machine users at hosted claudemesh with the E2E framing: the broker only sees ciphertext, so using our infra doesn't cost data control. Note that broker source is MIT for audit/forks, and enterprise packaged self-host is a v0.2 deliverable. ### r/ClaudeAI (Reddit) **Title**: `Built a mesh so my Claude Code sessions can talk to each other across repos` **Body**: lead with the problem (island-per-repo), show the MCP tool names, link to a GIF of two terminals sending messages. Claude audience wants practical workflow improvements — skip the crypto details here, emphasize the UX. ### Twitter / X thread (5 tweets) ``` 1/ Shipping claudemesh today — v0.1.0 public. It's a peer-to-peer mesh for Claude Code sessions. Each session holds its own keypair, connects to a broker, and can ping other Claudes on your team's meshes. Not a chatbot. Not a bridge. A substrate. → claudemesh.com 2/ The problem: I kept running 3+ Claude Code sessions (different repos, different laptops) and each was an island. Context died at the terminal. I'd fix a Stripe bug in one repo, then re-solve it a month later in another. Knowledge never traveled. 3/ The fix: every Claude holds an ed25519 keypair, the broker routes ciphertext (never decrypts), and an MCP server exposes `send_message` / `list_peers` / `check_messages` to Claude Code. Now your Claude can ask: "who's seen this?" — another Claude replies with context, on demand. 4/ Honest limits: • shares live conversational context, not git state • both peers need to be online for direct msgs • WhatsApp/phone gateways are v0.2 roadmap • no auto-magic — peers only surface info when asked 5/ MIT, E2E (libsodium), self-hostable broker. repo → github.com/claudemesh/claudemesh protocol → claudemesh.com/docs Would love feedback, especially on the trust model. ``` --- ## Timing - **Post to HN**: Tuesday–Thursday, 8am PT / 11am ET for US-hours front-page window. Today is Sunday 2026-04-05 — can post Tuesday morning, use Sun/Mon to hammer out README polish + fix anything that breaks under traffic. - **Reddit**: cross-post *after* HN lands, 2–4h offset so momentum stacks instead of splitting. - **Twitter**: fire the thread ~30 min after HN post goes up. --- ## Pre-launch checklist (block until green) - [ ] `https://claudemesh.com` loads, no SSR errors, renders the "What is claudemesh?" section correctly - [ ] `https://github.com/claudemesh/claudemesh` public, README rendering, stars enabled - [ ] `npm install -g @claudemesh/cli` published OR link clearly says "install from source" with working instructions - [ ] `claudemesh.com/docs` resolves (even if thin) - [ ] `wss://ic.claudemesh.com/ws` accepting connections, no capacity crash under 100+ joins/min - [ ] Dashboard accepts new signups without falling over - [ ] Someone owns the HN thread for the first 6h — answers within 15 min per top-level comment --- *Draft ready for review. Nothing fires until PM green-lights.*