CCXT Integration about gryphon

[brizzbuzz]

https://github.com/ccxt/ccxt

[asmodehn]

My 2 cents here, is that ccxt seems to favour quantity over quality (most exchanges are just "partially" supported, with some features that don't work, etc.), and the python code produced is autogenerated (I believe ?), which means it is not the primary language for working with it.

Although I do get the argument for reusing something that already exists instead of reinventing the wheel, there are already other trading bots out there relying on ccxt, and I was personnally quite happy to see that gryphon has his own python-based implementation of exchange client code, and that it doesnt attempt to connect to everything out there.
I interpreted that as a desire to focus on quality over quantity, which I appreciate even more when it comes to trading.

That said however, attempting to unify the API so that a dedicated user could "dropin" ccxt as a replacement if he wished to attempt to connect to exchanges that are not integrated in gryphon just yet, could be a useful exercise...

[garethdmm]

I'm open to this, or using CCXT selectively to make it quicker to implement hotly-requested exchange pairs.

Aside from what @asmodehn said, the one thing I'd really like to think through about this is security. Does adding a 3rd party exchange library introduce any new vectors to attack users of Gryphon? e.g. what if one of the maintainers of CCXT goes rogue before we/users notice, or what if a contributor slips a change in that reads environment variables and sends them to a their email under the maintainers nose? This is a risk with any library we use, but no library used by gryphon today is explicitly a cryptocurrency trading library, so would be a hot target.

There might be ways to reduce or nullify those risks, I'm not sure either way right now. We do use a 3rd party library to simplify an integration in one place already, which is coinbase, but in that case it was Coinbase's own code, so it was a bit of a different situation.

[brizzbuzz]

I definitely agree that support is a good question for CCXT, perhaps limiting list to "fully supported" at least initially would satisfy fears in that regard.

Haven't dug into the gryphon (or the CCXT) code enough to truly pros/cons of each connection methodology, though I'd imagine both are simply just relying on the default APIs provided by each exchange, not sure how much there is to optimize one way or the other in that regard.

I really like the idea from @asmodehn about offering the support as a "sidecar" in some manner, allowing Gryphon to flesh out it's API support while offering broader short term support.

@garethdmm in regards to security that is always priority 1 when it comes to open source haha... This is particularly valid with projects that seem to value speed over all, their release cycle is honestly insane, I count 8 versions released today already https://pypi.org/project/ccxt/#history I definitely think if this feature is added we certainly want to pick a major version and stick with it, usually best to not be on the bleeding edge of open source because that's how you cause injuries :P

One thing that particularly interests me is that CCXT is planning to do a "pro" version with websockets support ccxt/ccxt#56 To me this is a good reason for offering CCXT as an option rather than the base mechanism, because the goal here is to keep Gryphon free and independent, while still giving devs and traders the freedom to make their own choices :)