Don't Code And Drink..

Building a low-cost, decentralized web-based TTRPG runs into a practical networking wall: most home users lack public IP addresses, and the usual client-server approach breaks down when NAT and ISP address translation hide each player behind changing private IP/port mappings. The workaround comes from the 1990s-era networking standards that enable peer-to-peer connectivity—STUN, TURN, ICE, and WebRTC—designed to help browsers find paths through NAT without requiring static public addressing. The central insight is that WebRTC’s connection-oriented data channels can be used as a transport layer, even for workloads that look nothing like “real-time voice/video.”

That’s where the project turns into a long, messy engineering detour. The plan is to “twist” WebRTC’s data channel into something that behaves like HTTP and WebSocket messaging: send messages, get responses, and avoid building a full server-side stack. But WebRTC is browser-native, and there’s no official WebRTC support for Node.js, forcing the developer to hunt for libraries that can bring WebRTC-like behavior to a Node environment. After trying multiple libraries—some stale, some broken, one only partially workable—the implementation mostly works but still demands significant changes, especially around message sending and reliability.

To avoid wrestling with WebRTC internals directly, the solution becomes an adapter layer: stand up a WebRTC “server” that smuggles data into a real backend server, then converts responses back into the messaging format expected by the WebRTC client. The adapter effectively recreates HTTP-style request/response semantics on top of WebRTC’s underlying unreliable transport assumptions.

The pain doesn’t stop at connectivity. When reliable delivery is needed, the protocol choice matters: WebRTC’s SCTP-based reliable data path supports fragmentation, but browsers can’t be relied upon to implement it, so the developer ends up building custom fragmentation and reassembly in JavaScript. That leads to a homegrown, JSON-based messaging protocol that must carry message type, versioning, and length—plus image payloads encoded into the JSON (typically via Base64). The result is a “version + type + length + payload” framing scheme, essentially a mini binary protocol bolted onto text transport, with explicit buffer allocation and reassembly logic.

The takeaway is less about achieving elegant architecture and more about learning through brute-force implementation. The rant lands on two lessons: first, read the original RFCs and standards early—many secondary articles are incomplete or misleading; second, building the hard parts (like RTP, TURN/ICE plumbing, or your own protocol framing) is a fast way to understand how systems actually work. The project ends as both a cautionary tale for anyone attempting WebRTC outside its comfort zone and a pitch for “do the thing you think you can’t,” because the engineering understanding gained is the real payoff.