product

Local CC ↔ WebSocket Channel

The underlying mechanism that makes all of Same Project possible.

The mechanism

Every docked Node holds open a single bidirectional WebSocket to the relay. Every connected client (browser, mobile, anywhere) holds open the same kind of WebSocket. The relay is the only path between them.

Code stays on your LAN. Only intent and results travel through the relay. The connection is bidirectional — Claude streams its tokens back the same way.

Why WebSocket and not HTTP

Three reasons that all matter:

1. Bidirectional streaming. Claude’s response is a stream of messages. The user is also streaming intent (typing, follow-ups). HTTP request/response makes both feel laggy.
2. Many subscribers. When a Node broadcasts state to N clients, a persistent socket is dramatically simpler than long-polling each one.
3. Latency tolerance. A 5-second round-trip is invisible to a vibe-coding workflow but devastating to anything that wants to feel “live.” WebSocket lets us absorb the round-trip without the UI feeling stalled.

Why outbound from the Node

The Node opens the WebSocket outbound to the relay (not the other way around). This is what makes Manifoldone work behind corporate firewalls and residential NATs without any inbound port configuration. The relay is the public surface; the Nodes are clients to it.

Why the relay is stateless

If the relay held Thread state, every Node would be tied to a specific relay instance. That breaks horizontal scaling and complicates failover. Keeping the relay as a pure router means we can add capacity by adding instances, and any instance can serve any Node.

What’s parked

The full security model — exactly what OAuth scopes look like, how approval flows work for cross-user Thread access, how the relay validates Node tokens — is being designed in a separate spec. See the architecture security page.