Consider porting to use CCXT exclusively.

[xloem]

I'm wondering if it would be of benefit to produce a ccxt-only fork of zenbot, which eliminates the separate exchange extensions and simply uses ccxt to enumerate exchanges.

Work would then be to port upstream any features lost in this change, to be included in ccxt itself.

Making this change would decrease any duplication of effort between the two projects.

[station384]

reasoned argument: In my opinion no. not currently. ccxt does not fully support websockets, nor does it support some specific exchange calls (both of these things they are working on). I have recently used it to get hitbtc exchange online, continuing someone else's work, but a major portion had to be rewritten in the exchange code, and I couldn't support websockets yet with it, which would reduce call time drastically.

I have also started code to start supporting some of the other exchange supported by ccxt, and ran into error handling issues unique to each exchange (ccxt doesn't map all errors to common results, yes it puts the error in the same property, but the error can have different meanings on different exchanges), so it isn't as easy a just creating a new wrapper, it takes a bit of work and money as to test a new exchange properly you have to trade on the exchange, and to do it in a reasonable time you have to be willing to lose coin at times buying high and selling low :/

Now on a less negative note, I have been planning on doing what you are saying, but not by replacing the current exchanges in zenbot, but creating alternative ones using a common base. i.e. gdax and gdaxalt or something like that. where gdax uses the native and gdaxalt uses ccxt, albeit without using websockets :/ Priorities for exchange implementations would be exchanges not currently implemented in zenbot to expand its exchange support, and creating alternatives for existing ones if interest is still there and ccxt proves itself (don't really doubt that it wouldn't) on the other exchanges (why redo existing if you don't have to).

Due to specifics of each exchange. and example of this is how getOrder is handled

calling getOrder on gdax will return an order right after you create it. on hitbtc it can be up to 30 seconds after you create the order, till then with results in an error of order not found. there are other exchange oddities that I ran into that did this, and makes each implementation very specific.

Doing it this way and not relying on ccxt keeps it autonomous as well, if I wanted to implement an exchange not yet supported by ccxt, I can do it without having to push the change to ccxt first and relying on them to accept it.

emotional argument: I know there are counter arguments in opposite for doing just as you say, but doing so it feels like zenbot becomes a part of ccxt (reliant on it), and not ccxt being just a helper that zenbot uses.

1346 - Hitbtc working using ccxt

[xloem]

I guess I would say, rather than considering ownership or reliance between ccxt and zenbot, I would consider the entire ecosystem of open source code. We're all working together to make free tools for everybody to use.

If we can slowly work to migrate features needed for zenbot into ccxt, we allow others making other applications to share in the features we have made. Similarly, when they add features, we can share in the work they have done. If work is consolidated into fewer places, it eventually can happen much faster, as people do not need to duplicate effort.

If you ever change your mind and decide it might be nice to port more exchanges upstream to ccxt, I'd be happy to throw some bounty money towards issues that would further that goal.

My situation is that I would like to add features to bitcoin exchanges apis, and my goals don't exactly line up with either zenbot or ccxt, so I am unsure where to contribute the work.