Translate gRPC calls to make them CCXT-compatible
We aim to make xud's main calls ccxt compatible, so that professional traders can easily connect their existing GUI + algorithms. As per https://github.com/ExchangeUnion/xud/issues/471#issuecomment-441451581 we will not start a GUI project on our own.
Here is the full list of all unified ccxt API methods (subset of methods common among the exchanges) which we should support. I suggest to do this with a ccxt wrapper, not touching existing calls. The CLI is not affected and can stay as is. Goes without saying - we'll keep all other calls as is
@kilrau Is anyone planning to work on this? if not I will take it.
Please, but let's discuss on the way how to do this - if via ccxt wrapper around our current gRPC or change the gRPC
@kilrau @sangaman We should discus this on the weekly meeting.
@kilrau @sangaman We should discus this on the weekly meeting.
Sure! Weekly call on Wednesday 16:00 UTC+1
Any questions left? @ImmanuelSegol
https://sparkswap.com/docs/integration/ccxt
I'm not familiar with CCXT and I don't think it's been brought up on one of the calls, but we can discuss next time. I'd expect that it'd be better to have a wrapper around our existing API.
I'd expect that it'd be better to have a wrapper around our existing API.
That's what I thought too!
Please bring this up on our next call on Wednesday and definitely don't accept that we skip you again! ;)
CLI is enough for 1.0.0. Moving to post-1.0.0.
Is this open to work? I would like to take this if this is avaible to work. And if I can work on this, can you give estimation salary?
It is! Added estimation. I suggest to keep us in the loop on how exactly you plan to implement this to make sure you are heading into the right direction!
@kilrau I think we need provide http api on xud if we want to use api trough ccxt. So I'll create grpc services for every ccxt api endpoint?
I think we need provide http api on xud if we want to use api trough ccxt.
gRPC is HTTP(/2)
So I'll create grpc services for every ccxt api endpoint?
gRPC wrapper services, internally pointing to the existing gRPC calls. That's at least how I imagined it. Thoughts? @sangaman @erkarl
I would like to take care of https://github.com/ExchangeUnion/market-maker-tools/issues/1 first though.