WebSocket (wss://) dial option for cross-machine connections so agents can reach a Cloudflare Workers hub

[Mearman]

Goal: the ExaDev team's agents communicate with each other through the wire-mesh hub deployed at mesh.exadev.io (deployment tracked on ExaDev/wire-mesh#154).

The gap, verified directly against the code: WireMeshTransport.connectToRemote dials raw TLS/TCP (wire-mesh-core/adapters/tls-transport), and Cloudflare Workers only accept HTTP/WebSocket inbound -- so agent-comms as it stands cannot reach a Workers-hosted hub at all.

The client transport already exists: wire-mesh's ts/packages/node exports createNodeWebSocketTransport, the exact path web-console uses against a hub. agent-comms just never wired it as a dial option.

Scope:

• Let the outbound cross-machine connection dial wss:// (WebSocket) in addition to the existing TLS/TCP path -- likely a transport option or a URL-shaped connectToRemote argument.
• End-to-end verification once Deploy cloudflare-hub to mesh.exadev.io and verify it live wire-mesh#154 is deployed: two agent-comms instances on different machines connect to wss://mesh.exadev.io, discover each other via gossip, and exchange DMs/room messages through relay pairings.

Everything else the topology needs is already merged: multi-party relay fan-out (wire-mesh#30), gossip forwarding + catch-up (wire-mesh#110/#124), and agent-comms' own completed migration onto the wire-mesh substrate.

[Mearman]

Scope honesty from live-testing the dial against production: the wss dial leg itself works (PR #150's fake-hub integration test drives the real handshake + connect_request protocol), but pointing connectToRemote at mesh.exadev.io hangs by design -- the cloudflare-hub is a wire-mesh RELAY hub (its DO deliberately drops manage-frames sent directly to it), while connectToRemote speaks agent-comms' coordinator-approval protocol and waits for a manage-ok that will never come.

What 'two agents DM through mesh.exadev.io' actually needs beyond this PR: an agent-comms hub-mode session -- connect via wss, acceptMeshSession, gossip the self-advert (the hub forwards + catches up), and route peer messages through relay-connect pairings -- a distinct integration design sitting on the P5/history layer of the migration, not a dial option. Filing that as its own issue rather than inflating this one; this PR delivers exactly the dial leg it claims.

[github-actions]

🎉 This issue has been resolved in version 3.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• v3.3.0
• GitHub release

Your semantic-release bot 📦🚀