rtc-bridge

https://rtc-bridge.voltrevo.com

Access TCP services directly from the browser over WebRTC — no domain/TLS required on the node.

                    ┌─ signaling ──► coordinator ◄──WS── rtc-bridge node ──TCP──► service
Browser ────────────┤                                          ▲
                    └─ WebRTC (direct, post-signaling) ────────┘

Nodes dial out to the coordinator (no public IP or open ports required on the node). The browser connects to the coordinator's HTTP API to discover nodes and exchange SDP, then establishes a direct WebRTC connection.

Components

Binary	Purpose
node	Node that bridges WebRTC data channels to local TCP services
coordinator	Discovery + signaling server
echo	Test TCP echo server

Quick start

# 1. Build
go build -o node/node ./node
go build -o coordinator/coordinator ./coordinator
go build -o echo/echo ./echo

# 2. Start the coordinator
cd coordinator && ./coordinator init && ./coordinator run

# 3. Configure and start a node
./node/node init   # generates config.json5 with a fresh keypair
# Edit config.json5: add your service(s) and set the coordinator URL
./node/node run

# 4. Open the demo in a browser (coordinator serves it at /)
#    Enter the coordinator URL → Connect → click a node card → Ping / List services
#    Click a service chip to open a bridged terminal panel (nested under the node)

Node config (config.json5)

{
  // Services this node exposes: name → host:port
  services: {
    myservice: "127.0.0.1:7777",
  },

  // Coordinator WebSocket URLs to register with
  coordinators: ["ws://coordinator-host:8765/ws"],

  // ed25519 private key (base64) — generated by `init`
  key: "…",
}

Coordinator config (coordinator/config.json5)

{
  addr: "0.0.0.0:8765",
}

Coordinator HTTP API

Endpoint	Method	Description
/services	GET	Returns {"svcName": ["nodeId", …], …}
/nodes	GET	Returns [{nodeId, publicKey (hex), services}, …]
/offer	POST	{nodeId, offer} → SDP answer
/ws	WS	Node registration endpoint

Protocol

1. Node dials coordinator WebSocket and authenticates via a joint-random commitment scheme (ed25519, replay-resistant).
2. Node registers its services and keeps the connection alive with pings.
3. Browser fetches /services, picks a node, and POSTs an SDP offer to /offer.
4. Coordinator forwards the offer to the node over WebSocket; node answers.
5. Browser sets the answer and the WebRTC connection completes.
6. Before bridging to TCP, the data channel runs a command loop:
   • ping → pong
   • list → JSON array of service names
   • challenge <commitment> / verify <r_client> → proof <pubkey> <sig> (node proves ed25519 identity; client can verify the nodeId matches)
   • connect <service> → ok, then the channel is bridged to TCP

Building

go build -o node/node ./node
go build -o coordinator/coordinator ./coordinator
go build -o echo/echo ./echo

Testing

bash test-coordinator.sh   # end-to-end: echo ← rtc-bridge ← coordinator ← cli-client