How does the update websocket protocol ideally behave?

[JoeyZ]

How does the update websocket protocol ideally behave? And what are a relayer's responsibilities for updates? The documentation is a bit vague at the moment.

Will it send you an update when an order:

is canceled?
is partially filled?
is fully filled?
expires?

I'm assuming all of the above. And how should this scheme be formatted for all of the above scenarios?

{
    "type": "update",
    "channel": "orderbook",
    "requestId": 1,
    "payload": {.....}
}

If it were me, I'd do something like the below to handle the above cases. But the docs only show the type "updated"

"type": "filled",   // Fully filled orders that are no longer available at all

"type": "updated",   // Partially filled or canceled orders

"type": "expired",   // Expired orders that are no longer available

[Brandon Millman]

@lampshade9909 I agree the spec is a bit vague. Basically our intention with the "updated" event is for a relayer to fire that event whenever it receives a new order and thats it. All other information that you described should be attainable by observing the ethereum blockchain

[Brandon Millman]

I added a couple comments here: e592d69 let me know if I can clarify further.

[JoeyZ]

Cool, thanks. Keeping it simple like that is fine. So it's up to the client to observe the blockchain and get more details. I'm building in some additional things to help notify the client of changes as seen above. And they can choose to either believe me and go with the info, or observe the blockchain and check that information themselves. One person doing some heavy lifting gives others the option of taking shortcuts.

[Tom Schmidt]

Closing as this is fixed with the orderbook aggregator (tk). Not going to bake into SRA.