Add HeadState / Snapshot to the Greetings message

[matiwinnetou]

Why

Now that it is possible to pass history=0 when opening a websocket connection and Greetings message is sent after history had been replayed (if somebody chose history=1), what becomes problematic is knowing in what state current remote hydra-node / network is. There is no GetHydraState request or anything like this.

What

We would like to request that Greetings message returns a hydra client current hydra state.

How

Greetings message could look like this:

{
  "tag": "Greetings",
   "state": "Open",
  "me": {
    "vkey": "d0b8f28427aa7b640c636075905cbd6574a431aeaca5b3dbafd47cfe66c35043"
  },
  "seq": 1,
  "timestamp": "2019-08-24T14:15:22Z"
}

state field corresponds directly to the Hydra State from the UML's state diagram and can be one of the following:

    Idle,
    Initializing,
    Open,
    Final,
    Closed,
    FanoutPossible

[matiwinnetou]

@ch1bo @abailly

Can we make content of Greetings welcome message different depending if somebody chose history=1 or history=0?

If somebody chose history=1, they have all the data replayed to them (they can just ignore it and cherry-pick what they want) but if they chose history=0, they have nothing but most likely they need at least two things:

• current head state
• current head snapshot (utxos)

history=0

{
  "tag": "Greetings",
   "state": "Open",
   "utxo": .... 
  "me": {
    "vkey": "d0b8f28427aa7b640c636075905cbd6574a431aeaca5b3dbafd47cfe66c35043"
  },
  "seq": 1,
  "timestamp": "2019-08-24T14:15:22Z"
}

[ch1bo]

A quick hack (I'm thinking to solve this properly, but still need to write the ADR) could be to:

• Only include the headState with value being one of Idle, Initializing, Open, Closed, ReadyToFanout, Final
• Create some kind of API model abstraction and take the existing ServerOutput data types to update the model on any events
  • this allows us to have the latest state available in the API server without changing the interfaces
  • such a model needs to be a TVar or similar, we could call it a Resource
  • create functions newResource :: (a -> ServerOutput tx -> a) -> Resource a, updateResource :: Resource a -> ServerOutput tx -> STM () and getResource :: Resource a -> STM a or similar
  • For the head state example: we could define a data HeadStatus = Idle | Initializing ... and define Resource HeadStatus where the HeadStatus -> ServerOutput tx -> HeadStatus function would be a trivial mapping from HeadIsInitializing to Initializing (we could even leave out the first a ->) in this case.
• On client connect do send a Greetings message with latest headState according to the model, e.g. headState <- atomically $ getResource headStatusResource

This comes at the cost of having another piece of data in memory which is in principle redundant to the core HeadState we keep track of. This underlines that this kind of keeping a model of the world (here: the status of the head) is a responsibility we could be easily moved out of the basic hydra-node operation, also at the cost having one more moving piece in the setup.

[ch1bo]

We'll be grooming this 👆 on tuesday and likely putting it on the roadmap as a next item.

[ch1bo]

This is a candidate for https://github.com/input-output-hk/hydra/milestone/8

[matiwinnetou]

The fixes which you made, are they only applicable to state or also to utxo?

I realised that if I only have state and no utxo, then I have to issue GetUTxO command anyway. It would be good to get both but only when history=0. When history=1 then I need neither state nor utxo because HeadIsOpen gives UTxO and state can be figured out easily as well when history is there.

[ghost]

What to do for utxo when not in Open state?

• empty object
• no field
• null

@matiwinnetou What would be best for you?

[matiwinnetou]

null is fine

[matiwinnetou]

no field = null after all in JSON