Credentials.

[ashwinphatak]

Credentials for parties and items.

• [x] Create spec (requirements).
• [ ] Design how credentials will work for parties, replication, items.
• [ ] Update chess test to use credentials.

Credentials will use simple signed message, not VCs.

[richburdon]

Pseudo code for tournament test.

State machines correspond to bots or pads and subscribe to views (queries). i.e., sm => view(query)

• ISSUE: I'm conflating state machines and "apps" below (SMs should just subscribe to messages, whereas the app can do things -- which typically results in something being written to a feed)
• ISSUE: does all of this work when not live (e.g., close app mid game, then re-open and restart existing game)? Maybe related to above. E.g., the lobby pad (where users wait for games to start) will respond to invites. but if you restart the app -- how do we know if invites are still relevant? presumably you can't accepts twice -- since you can't write until you have your complete feed? but what if you do from different devices? @dboreham?

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)    

[ashwinphatak]

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