[client] Revise the player-finding process

[joshuaauerbachwatson]

1. There is currently a confusing difference between the player finding process in multi-peer versus server-based and neither is particularly rational in its design (see next).
2. It is unclear whether player finding is supposed to be immediate and tightly coordinated, or whether it can be allowed to stretch out over a longer period. The "min" and "max" players constructs suggest that time might be taken when in fact there is usually less than a minute before various time limits kick in. The idea of keeping groups around (by saving them in a local document) suggests that they can be used and reused, but server timeouts actually preclude that.

Proposed improvements:

1. Eliminate the min and max players idea in terms of just a simple player count.
2. Reorganize the server-based finding protocol to avoid contacting the server before all the players have their tokens and are ready to start.
   • this likely means combining Groups and Players, making Search a button in the dialog. The top level button should probably be called Players. Groups should be unnamed since they really are, anyway.
   • the group label becomes useless if groups are unnamed. The distinction between "nearby only" and "widespread" can be made in the Players dialog and/or the Game dialog but need not be shown at top level.
   • Probably the buttons can be consolidated after this change. We need to show four player labels, Help, Players, and Game. Once a game is started we need End Game and, for the player whose turn it is we need Yield. Show will be eliminated in issue #19.
3. Either revert to the random selection of "first player" for server-based, or permit both protocols to designate a first player by a means that is orthogonal to the token distribution scheme. One simple idea is that a player can request to play first. If more than one requests to play first, the one chosen is arbitrary, but, at least with prior agreement the first player could be unambiguously chosen by the group. Request to play first could be part of the new Players dialog.

[joshuaauerbachwatson]

Since the server will no longer be involved in generating game tokens, there is a question of what happens when a new token arrives for the first time. I think the server should just go ahead and create the game, but that in turn means that all calls that could result in the commitment of resources must be protected by the app token. Otherwise, a DOS attack could be mounted be just generating arbitrary game tokens.

[joshuaauerbachwatson]

There are quite a few moving parts here. Will try this ordering:

• [x] Revise the server protocol to eliminate the specialized /create path and to protect every call with an app token (later to be replaced by an auth0 login in issue #13).
• [x] Revise the player finding details to use only a number of players and not a min or max. Tweak the dialog accordingly. This may change again when we establish a special "first to play" player.
• [x] Consolidate dialogs and buttons to the new scheme, including a way to claim the "first to play" status.

[joshuaauerbachwatson]

It is worth writing down the new server protocol. I am not committing it to a separate document because it will change again under issue #5.

• Eliminate both /create and /delete. We create on demand and delete by garbage collecting in the existing timer-based regimen.
• /newstate inputs are appToken, gameToken, player, state.
• /poll inputs are appToken, gameToken, player. In the gRPC revision this would be eliminated in favor of a push notification.
• /withdraw inputs are appToken, gameToken, player.
• /reset and /dump require only the appToken.

This means that for the moment, anyone who has exfiltrated the appToken from the app can do a dump or reset operation (the app itself provides no support for these but it's trivial to write a script to do them from a computer). That's not good, but I would argue that anyone who manages to exfiltrate the app token can mount a variety of attacks. What's needed is a more auditable system of personal identity tokens backed by a login, where these "ordinary" tokens do not confer the ability to use the administrative operations and can be revoked upon evidence of bad behavior.

[joshuaauerbachwatson]

Having changed the server protocol as indicated, I now see that it is easier to play the game even with the current not-quite-optimal dialogs. The group can just make up a token and use it. In fact, the local game table (which I thought was useless) is actually quite useful in remembering tokens for different games you might want to play. While it's true that the server state associated with a game is garbage collected quite aggressively now when the game goes idle, that is complimented by the fact that game state is entered into the server on demand (there is no longer a "create" operation). The idea of eliminating the min/max confusion, creating a "first to play" indicator, and consolidating the buttons and dialogs remains valid, though, and I will continue with that.

[joshuaauerbachwatson]

This is looking pretty good now. Will open point issues for any problems discovered later.