Discord bot implementation

[froggleston]

I've been tinkering with a discord bot implementation and have got something working, but I am not sure if I'm going about it in the right/sensible way.

Currently someone that wants to use my code would have to:

• pip3 install discord.py
• Create a Discord Developer account
• Register a new application as per the discord.py docs
• Copy the token ID from this process
• Put my discord bot script wherever the FT bot is running
• Configure the script with a yaml file, including the token ID and pointing to the local bot instance API
• Run the script in screen/tmux
• Connect the bot to the chosen discord server

Does this seem unfeasible for users? Is there a better way?

[xmatthias]

i think the "developer account / register new application" part is pretty ... difficult to explain with reason - and quite some barrier to entry - at least for non-technical people.
I don't think you'll have much other choice though, at least not from how i understand discord bots.

For the script - I'm not sure an external script pointing to the API provides much benefits other than complexity (having a separate script that's going to be installed, keeping that script running in parallel).
If you think this is a must have - I'd probably prefer having this integrated into the RPC modules as a separate point (similar to telegram - most likely reusing/extracting formatting from telegram so we have to maintain certain logic only once).

You'll also in reality need one new application per bot (assume you run 10 bots - you'd need 10 applications). While not a huge problem - it's also not very convenient to setup - and I'm not sure how this would work if multiple bots would have to join the same server (which bot should respond to $forcebuy XRP/USDT) ? ... but in the end, similar to telegram if done correctly

---

You should also keep in mind that a discord server is usually intended to be a community - so the base assumption is that there's multiple users in one server with access to this.
Obviously permissions can be restricted on that channel or so, but i think the base assumption must be that it's not.

as such - you'd then end up in a scenario where everyone has access to send commands to a bot. Assuming a full implementation, this would include also /forceentry /forceexit commands ...

[froggleston]

If you think this is a must have - I'd probably prefer having this integrated into the RPC modules as a separate point (similar to telegram - most likely reusing/extracting formatting from telegram so we have to maintain certain logic only once).

I'm not sure how this would be done, given that the discord bot has to run within it's own client thread. I'll try to do more digging.

You'll also in reality need one new application per bot (assume you run 10 bots - you'd need 10 applications).

No, as long as the bots are on the same system, then this should work as is by supplying the list of servers in a yaml just like frogtrade9000. I also think it would work if you're running on a VPS with the API bound to 0.0.0.0. I've implemented basic HTTP auth with aiohttp. I guess this is the benefit of having a separate script/tool rather than it being integrated into the current RPC implementation. Within RPC, yes, it would be one discord bot per FT bot instance.

I'm not sure how this would work if multiple bots would have to join the same server (which bot should respond to $forcebuy XRP/USDT) ?

Currently, you would get the list of configured servers with $servers, then call $forcebuy <server_name> <pair>

as such - you'd then end up in a scenario where everyone has access to send commands to a bot. Assuming a full implementation, this would include also /forceentry /forceexit commands ...

Yes, correct, so this would need to be made explicit with instructions about how to restrict who can post commands in that particular discord channel through normal discord permissions

[xmatthias]

given that the discord bot has to run within it's own client thread

so does the webserver ...

Personally, i think that a "per freqtrade" instance bot will be easier to digest / read - as you'll know "this comes from Bot XYZ" (similar to telegram) - but i guess that's personal preference.

in reality, your "script" approach will clearly work (never said otherwise). but i don't see that way as being integrated into the freqtrade repository at the moment, not as script (scripts are usually high maintenance - or rather low maintenance until they break and noone notices - usually contain no tests - and therefore prone to break).

Obviously that won't prevent this as as standalone / separate project providing the script.

I could however imagine a discord-bot sub-command - which will work like this - but it's obviously more work / effort to bring this into the system properly. Even this will need further consideration - as it might be beneficial to have this published to pypi separately, without the "heavy" freqtrade dependencies ...

As a side note - you'll also need to be careful with "bot is not up" - as that can block your whole setup if you're not careful (request timeouts ...) - but that's then details to figure out within the implementation.

[froggleston]

Sure, I wasn't intending this to be integrated at this stage as it's super early. Just wanted some initial feedback :)

I suppose the good thing about the integrated approach is that once you've set it up, you don't need to adjust anything if you change/update the strategy etc. Hmm I didn't think of a separate command - I was thinking around a config-managed "discord-bot": {"enable":true}, kind of thing... Interesting.

[xmatthias]

assuming you want it to be "multibot" based (Which i understood from the above) - then I'd assume you'd want to run it standalone (so it's detached from any other bots / bot tasks).
obviously you can run it with a dry-run ... but what if you decide to disable "exactly this" bot - then you're without discord until you notice.

my comment about "separate pypi package" was about the fact that you'd then avoid to install ta-lib, pandas, ... - which is not really necessary - at not using the approach when connecting to the api(s).