API to select "host" participant

webxdc
1

Adversarial games such as GitHub - webxdc/ChessBoard: A webxdc chess game for two players and many observers :) need to decide who is playing which side. Currently in ChessBoard it is implemented by someone clicking “Start game” to send game offer and then someone else clicking “Join game”. This is not reliable because it is possible that multiple people click “Start game” at the same time.

To reduce this problem it would be nice to have an API which tells whether the game is started by original sender of .xdc file or someone else. Since there is only one such participant, they can be a “host” which gets join requests, accepts the first one arriving and confirming.

API can be as simple as a window.webxdc.isOriginalSender which is true for the device sending the app (not even another device of the same participant receiving the message via bcc-to-self) and false otherwise, or undefined in case of outdated messenger which does not support this API yet.

2

I solved it in the tic-tac-toe app by letting the host approve the join request (announce who actually joined):

  1. Host opens game
  2. multiple people send join requests
  3. Host confirms/starts the match with the first join request that was received.

Though this solution is mainly for “tournament” style games that can have multiple matches simultaneously.

3

How does host in tic-tac-toe knows that it is a host and should wait for join requests instead of sending own join request?

4

TBH this sounds like bloat. I think the problem you’re describing can be solved with cooperative conflict resolution.

  • Along with the “start game” message send a timestamp when the button was pressed.
  • Upon a conflict, just make the host the one who has the smallest alphabetic selfAddr (or the smallest hash of selfAddr)

In addition, I think webxdc.originalSenderAddr is better than webxdc.isOriginalSender

5

It sends the self address in the updates and does not answer to join request from the same address as the selfAddr. This could be improved when we have a unique userid that core would assign as metadata next to the payload.

1 Like
6

I’m working on a rock-paper-scissors app that uses a little bit of cryptography (a commitment scheme) to verifiably prevent malicious clients from simply delaying their choice until they’ve observed that of their opponent.

In this type of protocol everyone first locks in their choice (via cryptographic hashing), then once everyone has committed all moves are revealed and the outcome is computed.

The same basic idea can be used to simulate coin flips (or dice with a little more complexity). I wrote about this in two recent blog posts (the first, and its follow-up). While this doesn’t technically address the stated requirement (determining the “host” of the app), it can solve the example problem of fairly assigning playing order.

I know that the webxdc threat model tends to assume that chat members are honest and cooperative, so a design like this might be considered overkill. That said, the required cryptography is very fast (imperceptable next to things like graphics), so the tradeoffs for dealing with malicious clients comes down to:

  1. somewhat more network usage due to the two-stage protocol compared to WofWca’s selfAddr sorting

  2. the requirement of significantly more expertise to implement it correctly

The first issue hardly matters in practice, because you’ll probably take turns playing first in iterated rounds of tic-tac-toe or chess. The second is the much bigger obstacle, but the whole protocol could probably be implemented as a library providing some kind of “Game lobby” UI with all the cryptographic details abstracted away.

My rock-paper-scissors app is mostly intended as a prototype for some more complex games that I want to develop, but if there’s sufficient interest I could think about generalizing some of its back-end.

3 Likes