Let's get kraken (🙄 ), on orders..

[goodboy]

As mentioned, we need new and improved kraken support for orders after the changes to the clearing system to include strict typed messaging semantics as per #190. There was ad-hoc support for this before that PR landed but the code is imo not usuable and was always a bit hacky by fitting too much to the ib backend schema that was in place (due to it being the first broker with full live trading support).

This issue is more or less a duplicate of #194 but for our kraken backend so please use the detailed resources in that issue as a reference as well (and vice versa if anything useful get's stuck here @guilledk).

---

The technical details of how to implement the 2 way streaming endpoint trades_dialogue() is in the first bullet in #194 and both the paper engine and current ib backend implementation should be used as reference.

• before you do anything else you're going to have to add authentication code to connect to a user's account and get an api key.
  • private user api tokens/data for this will ideally be stored in our brokers.toml under a kraken section (i no joke, somehow lost the schema i had originally in this file bc i was lazy and forgot to put it in git..)
  • make sure we're adhering to the api's rate limit constraints
• the first bit to relay from the trades_dialogue() endpoint is the open set of positions likely from the account balance ReST endpoint (so not websockets)
  • this data can be related back to the EMS as a sequence of BrokerdPosition messages as is done in the ib case
• NOTE: there's 2 options for sending order requests and not sure which one is going to be better (i had previously done websockets but the rest approach might be a lot simpler and more deterministic?):
  • using the rest api: https://docs.kraken.com/rest/#tag/User-Trading
  • using the websocket api: https://docs.kraken.com/websockets/
    • be sure to read the general considerations there.
• next, you'll likely want to dig into the websocket api to leverage the real-time streaming for sending updates to our EMS:
  • live trades endpoint: https://docs.kraken.com/websockets/#message-ownTrades
  • create / modify order endpoint: https://docs.kraken.com/websockets/#message-addOrder
  • cancel order endpoint: https://docs.kraken.com/websockets/#message-cancelOrder
  • a cancel all orders endpoint: https://docs.kraken.com/websockets/#message-cancelAll
    • this could in theory be exposed to the EMS as a new message if we wanted, some kind of BrokerdBatchCancel maybe?

---

Additional resources from chat:

• paper trading engine code as reference: https://github.com/pikers/piker/blob/master/piker/clearing/_paper_engine.py
• equivalent ib backend order entry endpoint: https://github.com/pikers/piker/blob/master/piker/brokers/ib.py#L1279
• new ems message types module: https://github.com/pikers/piker/blob/master/piker/clearing/_messages.py
• the new messaging layer uses tractor's very new bi-directional streaming apis and contexts; relevant issue resources are:
  • historical design and iteration on the new api: Bidirectional streaming? goodboy/tractor#53
  • implementation PR with tests and examples: Bidir streaming goodboy/tractor#209

Any questions please do ping.

[goodboy]

Oh, please branch off the new asyncify_input_modes branch as it will make manual testing far easier

disregard, everything is on master now.

[iamzoltan]

are there remaining sections in this issue that we can tack onto to #290? or should we keep this issue open?

[goodboy]

@iamzoltan no I think this is mostly first-draft complete right?

This can obviously serve as a source for driving refinements in #290, but also I do think we may end up wanting the ws APIs supported for latency down the road?

I think for now this is definitely complete though 🥳

[iamzoltan]

sweet, I thought so. There are points here I haven't addressed, which was why I asked, but keeping it for reference is a good idea.

on the to the next PR.