Player flows
Tinychess will not have sign ups, instead an auth less system based on server side token generation will be a better idea.
This decision is due to the expected way of using this, to play with friends in a group or small scale tournaments in school. Sign ups and logins for such small duration use is going to be bad for user experience. Just let people play.
However measures will be taken to prevent users from gaining write access to other users’ games, and nicknames can be added to enable identification of players active on the server.
Player creation
When a player opens their client for the first time, it sends out requests in its local network to identify the server of tinychess (using broadcast UDP or mDNS). Once a server is found, the process of player creation begins.
- Server assigns the player a server-generated id on first connection.
- Client stores this id token in their storage, for persistence.
- After this an access token is generated by the server, and sent to the user.
- On reconnection, the player id is used to check for ongoing games (rejoin) or go ahead with the normal processes of playing/watching games.
Concerns (Mostly security related):
- Multiple servers on same network/server spoofing.
- Sharing of player_id file to another client machine - risks identity leak.
- Client working from multiple devices - will not have same player id. Also one machine - one player id. 4.