Summary

After discussions with the Hummingbot community in the past few weekly developer calls, there appears to be a consensus supporting a improvement bounty to enable orchestration, enabling Hummingbot instances to be controlled by a third party interfaces, respond to external events, etc would be highly beneficial to everyone.

Community members klpanagi and TheHolyRoger have existing work that can be hardened and used for this:

• klpagani has forked Hummingbot and built a broker-based communication interface. See https://github.com/klpanagi/hbot-strategy-dsl for more info.
• TheHolyRoger has built a remote commands execution module along with an external TradingView web server. See [this forum thread] for more info.

Therefore, the Foundation proposes to fund a collaborative effort between the two of them to work together to deliver the Bot Orchestration project in 2 phases.

Since this is a substantial amount of work with a lot of value to the community, we believe that 2,000,000 HBOT, out of the 15,000,000 Dev Grant Budget for Epoch 2, should be allocated to this project, with 1M paid upon completion of each phase.

Proposal

Goal

The goal of this proposal is to enable remote control and monitoring of Bot instances towards a plugin-based approach of building HF AMM bots and the development of bot collaboration schemas in the future.

Implementation

The implementation is divided into two (2) Phases. In Phase 1, a thin communication and messaging layer will be injected into the hummingbot codebase to enable remote control and monitoring via a broker-based communication middleware, essentially supporting the MQTT protocol. Next, in Phase 2, an event and data layer will be integrated into the hummingbot codebase to support receiving and handling remote events via the message broker (MQTT), such as the case of TradingView signals.

Phase 1 (1,000,000 HBOT)

A broker-based communication middleware will be integrated into the hummingbot codebase in order to allow for:

• Remote execution of Bot Commands
  • Start
  • Stop
  • Import
  • Config
  • Balance Limit
  • History
• Remote monitoring of Bots
  • State monitoring via heartbeats send to the broker
  • Remote Logging. The Logger class will be refactored to also send logs (optional / enabled by default) to the broker
  • Remote Notifications - The Notifier class will be extended to send notifications to the broker

An MQTT broker will be used for the implementation of the communication middleware, as a single point of reference for communication between bots and third-party software and services.

The configuration of the broker endpoint (Host, Port, Credentials etc) will be in the 'conf_client.yml' file so that these parameters can be seen as normal global bot parameters.

Finally, deployment scripts for the EMQX message broker will be delivered and integrated into the hummingbot codebase.

Phase 2 (1,000,000 HBOT)

In this Phase, an event and data layer will be integrated into the hummingbot codebase to support receiving and handling remote events via the message broker (MQTT), such as the case of TradingView signals.

More specifically, an MQTT event listener will be developed and integrated into the hummingbot codebase, which will provide configuration for setting the URIs of the events to listen on. Upon receiving an event, a handling callback provided by the user/developer will be executed by the MQTTEventListener, so that users operate/develop their strategy based on the input event.

In the context of Phase 2, the RogerThat TradingView implementation will be delivered as an individual module and will bridge TradingView signals to bots (TradingView -> MQTT broker -> Bots) for developers to be able to use them within their strategies. The aforementioned MQTTEventLlistener will provide means of consuming TradingView signals within strategies, in the form of external events and callback functions.