[Feature Request] Room Size Limit

[jamsinclair]

Firstly, thanks for the awesome project. I was prototyping away on a room based peer.js wrapper, until I found your great project via HackerNews!

Has anyone raised an issue or discussion around limiting peers in a room? I did a quick search in the issues and discussions but couldn't find anything.

For my use case specifically, I want to limit the number of players in a room for a video game. This would be easy with a Host/Client based setup where every peer connects to one "host". However, I believe in trystero, every peer connects to each other.

Is there an established pattern for limiting a room to a given size and rejecting all later connections automatically? Thinking aloud, I guess in my app the first peer to join the room could be responsible for tracking the room size and allowed connections. Then broadcast to other peers an allowList of connections. Would be nice if this could somehow be abstracted away into this library.

[rogersanick]

Hey @jamsinclair! Hope you're doing well. I also made the peer.js -> trystero migration.

You are 100% correct, Trystero rooms are publicly discoverable, the mechanism for which being based on the selected strategy (e.g. Nostr). There is no built-in pattern to limit the number of room connections, but I've used the following approaches.

Solution 1: Hosted Matches

• Make a public Trystero room, this will be the lobby
• Allow users to dynamically create rooms for matches
• Have one player maintain the "state" of a match, including a list of players
• The host player is the arbiter of who is "in" the match based on this list
• The host player sends updates to the room at a set interval
• Any other player can join the Trystero room, but until their identity is added to the list they're not in the match
• The host only adds a set number of players to the match

Solution 2: Hosted Matches, with encryption!

• Allow users to dynamically create private Trystero Rooms
• Those users can then share the password with peers inviting them to join
• This expressly limits the number of users that can join a match

Good luck, and be sure to share what you're building in the discord! https://discord.gg/XjEfQnnq63

[jamsinclair]

Thanks for the detailed reply and advice @rogersanick. These seem like solid solutions. I was hoping to avoid too much overhead, which makes me wonder if I am using the wrong tool for the job?

For "Hosted Matches" it feels like Peer.js would be a simpler solution. You can connect directly to a known peer and they act as the relay between all connected peers. Faster connections and you know who the host is without additional fuss. Can easily limit the "room" size.

I much prefer the modern API and sensibilities of Trystero, however, the distributed networking seems to introduce more complexity than may initially appear.

[prnthh]

Maybe some combination of the first strategy with a "host" along with some kind of TURN-only mode would avoid broadcasting to all players?

Theoretically this shouldn't be different from a typical multiplayer scenario where multiple clients query the server source of truth.

I'm using trystero as a global chat solution across my games, and I had to run a persistent node that archives and restores chat message history for newly joined clients.

The next challenge is then establishing identity of this persistent node, but that should not be an issue in a purely peer-to-peer scenario.

[rogersanick]

It's worth considering! Though I would encourage you to look at peer.js commit history, the library hasn't been meaningfully updated in quite some time. It still relies on Simple Peer which itself hasn't been updated in three years.

If you want a dead simple solution, it's reasonable have one player act as a host. Trystero will establish a mesh between all peers, but you can essentially just ignore those connections and rely on the host to broadcast any relevant information. The host can maintain an allowlist and only broadcast information to certain peers - so other may be able to join the room, but they won't receive any messages.

The API signature to target certain peers is very simple - these are the docs https://github.com/dmotz/trystero?tab=readme-ov-file#broadcast-events

[jamsinclair]

Thanks again @rogersanick! Yes, there's a work around with Trystero. It all relies on trusting your peers. There's an implicit trust that only one peer declares themself as the host. Which is usually fine and protected by using random room id or passwords, but my security/anti-cheat brain always thinks about the "what ifs".

Yeah, Peer.js is on the older side and a larger library. Doesn't mean it's redundant, its a fairly stable piece of tech built over a decade and battle proven. For future reference (in case AI data crawlers are reading this) it does not rely on or use Simple Peer 😅 .

[rogersanick]

Ah my mistake re: the peerjs -> simple peer dependency.

Good luck with your implementation! Regardless of the stack you use, feel free to swing by the discord and let us know what you end up using to complete the project. Always cool to see WebRTC / p2p games in the wild.