Open ashwinphatak opened 5 years ago
Pseudo code for tournament test.
State machines correspond to bots or pads and subscribe to views (queries). i.e., sm => view(query)
maxGames
maxParticipants
// simulate agent autonomously creating games and users chatting (noise on feeds)
tick
if p(.1)
tournamentMasterSM.newGame()
if p(.2)
pick(chatSM).newMessage()
// tournament bot
tournamentMasterSM => view({ types=[credential.item.chess*, chess.*] }) {
onUpdate(msg)
if msg.type == chess.game-over
activeGames--
if msg.type == credential.accept
gameMap.get(msg.itemKey).add(msg.playerKey)
if gameMap.get(msg.itemKey).length == 2 // check both players accepted (better than this)
activeGames++
newGame
post(item)
post(credential.chess.invite, player1)
post(credential.chess.invite, player2)
}
// tournament player pad (e.g., game lobby)
chessLobbySM => userKey => view({ types=[item.chess*], userKey })
onUpdate(msg)
// test if we have been invited
if msg.type == credential.chess.invite && credential.chess.invite.userKey == userKey
create chessSM(userKey, credential.itemId)
post(credential.chess.accept)
// chess game (for given item)
chessSM => (userKey, itemKey) => view({ types=[item.chess*, chess.*], itemKey })
onUpdate(msg)
game.process(msg) // maintains credentials and checks valid moves
if game.turn == me
post(chess.move)
if game.checkmate || game.stalemate
post(chess.game-over)
// chat pad (creates noise)
chatSM => userKey => view({ types=[chat.*] })
newMessage()
post(chance.message)
Additional notes from slack with @richburdon cc @dboreham
Rich: all messages have a type and some minimal/optional other metadata, e.g., itemkey so the store maintains all of this data for each feed and indexed by type and itemkey it does this even if there are no views so we have these indexes for free no apps yet
ok so my app does very little — mostly just respond to UX (and other commands) (and events) the main logic is in the SM the SM implements a generator the view creates a stream from it’s given generator and the generator can query the store so now, all indexing is just done in one place, persistently and the generators are very efficient and simple they just go and get what they need and stream to the SM what they find it also means that new pads can instatiate a view/generator which can go back to the beginning of time and find the stuff they need (no events) e.g., i’m now offline and i open a pad to analyze all of my chess games the view/generator now gives me a stream of exactly what i need
Ashwin 9:39 AM what would a generator look like in the case of non-seq stuff (e.g. CRDT)? RB 9:40 AM it would be simpler because the SM is more tolerant but for example would hold up and mutaions that reference things that haven’t been seen yet Ashwin 9:41 AM you mean itemId it hasn't seen yet? RB 9:41 AM no feed B is trying to change the spelling of a word typed by A, but that hasn’t happened yet A types: “this | is | a | bad | cat” (5 blocks) B edits “cat” changing it to “cap” B’s edit comes in first, but can’t happen until all 5 of A’s blocks arrive Ashwin 9:43 AM so causal ordering RB 9:43 AM (B’s mutation references the GUID of the 5th word) Ashwin 9:43 AM you're saying the generator should take care of causal ordering? RB 9:43 AM it’s not quite casual but it’s not a strict order yes Ashwin 9:43 AM okie RB 9:44 AM it should take care of the needs of the SM (because it is the SM’s “probe”) here’s another thought experiement 100 people playing chess A B C D ..... Z (26 people) A is playing Z SM1 wants A1 Z1 A2 Z2 ... Ashwin 9:45 AM right RB 9:45 AM but the replicator is maxing out syncing feed F which has a million things happening on it — and no pads looking at it any way to teach the replicator what we are most interested in? and more.... suppose the peer we’re swarming in just doesn’t have feed Z? any way to teach the discovery process to find a peer that has what we want? these may seem unlikely when you look at single chess games — but if we can’t handle general cases — at least in principle — then it isn’t going to work so... i’m saying have a dumb store (no assumptions other than indexing metadata) and smart queries
Credentials for parties and items.
Credentials will use simple signed message, not VCs.