8.8 KiB
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.comloads, no SSR errors, renders the "What is claudemesh?" section correctlyhttps://github.com/claudemesh/claudemeshpublic, README rendering, stars enablednpm install -g @claudemesh/clipublished OR link clearly says "install from source" with working instructionsclaudemesh.com/docsresolves (even if thin)wss://ic.claudemesh.com/wsaccepting 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.