currently can't be swapped over easily to MktPair bc we don't
relay enough info through the clearing sys msg set to reproduce
via the new `.from_fqme() method..
probably best solution is to instead require all backend's to
provide the MktPair msg directly as part of loading pre-existing
live dialogs?
likely pertains to #514, #466, #463, #220
[ ] deribit backend is still missing Asset usage in MktPairs and
i only wasn't able to due this due to having no account set up to get
the data APIs..
we should probably consider making a Cascade msg-type which
describes IO for cascaded Flumes? Probably something to get into
when we get back to formalizing that subsys XD
Lingering task(s) from #489 that we couldn't quite wrap up due to,
[ ] the
Symbolusage in.ui.order_mode:OrderMode.load_unknown_dialog_from_msg()https://github.com/pikers/piker/blob/master/piker/ui/order_mode.py#L641MktPairbc we don't relay enough info through the clearing sys msg set to reproduce via the new `.from_fqme() method..MktPairmsg directly as part of loading pre-existing live dialogs?[ ]
deribitbackend is still missingAssetusage inMktPairs and i only wasn't able to due this due to having no account set up to get the data APIs..[ ] there's a hacky shim-usage of
MktPairfor the fsp flumes inui._fsp: https://github.com/pikers/piker/blob/rekt_pps/piker/ui/_fsp.py#L493Cascademsg-type which describes IO for cascadedFlumes? Probably something to get into when we get back to formalizing that subsys XD[ ] #502 seems to be related to this as well?