The peer-to-peer fabric
Real-time play rides a capped WebRTC peer mesh between the humans on your board, with an authenticated WebSocket relay as the fallback, the signaling path and the home for bots. Because the binding result is recomputed from signed inputs rather than streamed from one server, the network carries feel and presence - not truth - which is what lets it shed load, not truth, as the crowd grows.
Real-time play rides a capped WebRTC peer mesh between the humans on your board, with an authenticated WebSocket relay as the fallback, the signaling path, and the home for bots. The network carries feel, not truth - which is exactly why the crowd makes it stronger, not more fragile.
#A capped, local mesh
Each pair of human rivals shares a single lossy, unordered data channel - the kind you want for 20-times-a-second position updates, where a stale packet is worthless and retransmits only add lag. The mesh is local by construction: you only connect to the rivals in your own region of the board-graph, the ones you can actually reach and affect. An arena tops out at eight boards, so you hold at most seven live channels no matter how large the match is; bots and anyone past that neighborhood ride the relay instead.
- Direct peers
- ≤ 7
- One RTCDataChannel per reachable human rival.
- Snapshot rate
- 20 Hz
- Kernel-packed position frames on the fast path.
- Unordered channel
- lossy
- ordered:false, maxRetransmits:0 - latency over reliability.
#The authenticated relay
Underneath the mesh sits a WebSocket match-room relay running a small frozen wire protocol - position, shot, flipper, a ram "bump", and WebRTC signaling. Joining requires an HMAC-signed token, so you can't wander into a room you weren't seated in. The server sanitises everything it forwards (callsigns, aim, colour) and re-emits each frame only to the other players in the room.
- auth
- HMAC-signed join token in the URL; a forged or expired token is closed on sight.
- room cap
- 100 members per match room; a separate read-only cap for observers.
- signaling
- WebRTC offers/answers pass through the relay to bootstrap the mesh.
#Binary wire, 20 Hz
The C kernel packs compact binary snapshot frames twenty times a second. They prefer the direct data channel and fall back to a binary WebSocket frame if a peer isn't meshed. Shot frames - the ones that actually matter - are sent over every available transport at once, and the receiver dedupes them. A lost path can add jitter; it can't drop a shot.
#The network carries feel, not truth
This is the load-bearing idea. Peers exchange presence, aim and predicted frames so the arena feels alive and immediate - but the binding result is always re-derived from the signed input-log, never from what a peer streamed. A laggy peer, a dropped channel, or an outright malicious client can make your screen briefly wrong; none of them can change the outcome, because the outcome isn't something anyone transmits.
#Rooms that span instances
One relay box has a ceiling. So a match room can fan out across many relay instances over Redis: frames publish to a per-match channel, each instance skips its own echoes, and every member receives each frame exactly once. You add capacity by adding instances, not by growing one server - the classic horizontal-scale shape, applied to a game room.
#Why more users sheds load, not truth
In theory the fabric benefits from a crowd on three fronts at once:
- The mesh offloads the relay. As humans fill a board, the 20 Hz hot path moves onto direct peer channels - the busiest part of the traffic leaves the relay exactly when the room is busiest.
- Redis spreads the rooms. More players simply means more relay instances sharing the fan-out, with exactly-once delivery holding the room together.
- More witnesses. Every archived match invites another independent re-auditor. The proof layer is content-addressed, so more users means more hosts of the record and more parties who can catch a bad settlement.
None of that touches correctness - it's redundancy and reach that grow with the population.