Beaker browser and the DAT format - thoughts on usage for multi-user experiences
some considerations on DAT and its features
Each DAT has a large hex id (chosen at random), which has several purposes:
- it inequivocally identifies the DAT archive itself
- it is used to encrypt the archive along the wire between peers
- it remains the same during DAT changes
Only one user/entity/machine can create and make further changes to the DAT archive. Those are file system changes such are create/edit/rename/delete for files and directories. Other peers can freely read the DAT archive given they know the URL aka hex id. They can explore earlier revisions of it. They can't change it.
A multiplayer game based on DAT, how?
For the purpose of multi-user experiences such as turn-based games, each player would have to use a DAT file, sharing it with remaining players.
Assuming that a game session is an array of moves, where each move features
- the user performing it (hex id)
- the action timestamp (may be relevant or not, depends on the game)
- the action itself, as complex as needed
How would it take place?
- a 2 player game starts (for simplicity assuming the 2 players scenario first)
- players would create DATs with an empty array of moves.
- players would share their DAT ids with the other player via alternate medium such as XMPP/IRC/slack/etc.
- players would subscribe the other's DAT
- player A would perform a move, that is, add a movement tuple to the array.
- player B would be notified of the change.
- if player B agreed on the validity of the array (that is, consider previous moves untampered, current move from other player in the correct timing and valid according to the rules), he/she would update his/her array with not only the state just validated but that appending his/hers too
- if player B would consider player A's array of movements invalid, he/she would notify the other of the bad veredict (possibly via DAT too, with an additional array of chat lines in his/her DAT) and would abort/leave the game player A would resume in the same manner: being notified of the previous move, validating the array, playing and saving...
end of game
the game could be considered finished with an agreed movement such as the empty one