multiplayer-p2p

Create the signaling relay and /api/rtc route from the reference files, then instantiate P2PRoom with a room id and callbacks, or copy the useP2PRoom hook. Call join(), then use broadcast() for game-rate state and send() for reliable events.

broadcast() uses an unreliable, unordered channel for continuously refreshed state like positions, where stale packets can drop. send() uses a reliable, ordered channel for events that must arrive exactly once, such as chat or game-start actions.

No. P2P has no server authority, so every peer runs its own copy of the rules and can lie about position or score, and peers learn each other's IP addresses during ICE. Use it only for co-op and casual play among people who choose to play together.

A full mesh is O(N^2) connections, so rooms should be capped at roughly 8 peers. Additionally, about 10-20% of peer pairs sit behind strict NATs and cannot connect, which surfaces as connectionState failed and should be shown in the UI.

Strict or symmetric NATs block direct peer connections for roughly 10-20% of pairs. The kit exposes this per peer as connectionState failed; you can override the STUN server with the VITE_STUN_URLS environment variable and restart the dev server.

Late joiners know nothing, so an existing peer must send() them the current shared state when they appear in the peers list. Exactly one peer answers: compare ids among peers already in the room and respond only if your selfId is the smallest.