As part of the rewrite, I decided to implement per-server configuration files. These config files allow server owners to enable, disable, and update different plugins for their server through a (mostly) simple command syntax from right within their server (there will never be a dashboard for Niftybot-Discord as I will not be hosting it publicly for large scale use).
What this means is that a few things had to happen:
- When the bot is added to a server, the server owner can generate the default configuration file, which follows the naming structure of SERVER_ID.ini
- Once generated, they can configure different aspects of the bot for their server (i.e. enabled welcome and leave messages and specify a channel for each)
- The syntax would follow:
- [prefix]config JoinPart welcome_channel_id CHANNEL_ID
- [prefix]config JoinPart member_join_enabled True
- The code behind the different cogs then has some logic to ensure the command / function is enabled, if it needs a specific channel it gets that ID, and then does what it needs to do
The configuration system is far from perfect as it sits, as a lot of cogs need hard-coded logic checks to ensure different settings are in the right format, as well as other things, but in the current state it does get the job done well enough.
Alongside the server specific config files, there is still the core bot configuration that handles the bot token, database name, etc. that cannot be updated from within discord and must be updated manually.
The second issue I wish to touch on is the changes to the Discord developer Terms of Service. One of the major things that was changed is that to store any information now we must get the express permission of the users. To combat this, I have implemented an “accept” cog. If a user tries to use a command and has not yet accepted the bot Terms of Service (which states that it stores publicly available information for later use, among other things), they will get a message telling them they must accept.
Once they accept, they are added to a table in the SQLite database and every time they use a command it quickly checks that their discord ID exists in the that table and if so it continues forward running the cog like it normally would.
There is no way to “opt out” of this accept right now once a user has, but that will be coming shortly alongside some method of preventing users from adding and removing themselves to circumvent or cheat at something (i.e. Betting Game).
Another change to the discord developer ToS is the requirement to encrypt all data. Although the userID, serverID, etc. are publicly available information (enabled developer mode and right click a user / server / channel and you can copy the ID), the new ToS states this data needs to be encrypted if stored. What this means is that at some point in the future I will be implementing encrypted storage for userID and serverID, as well as anything else that needs to be stored (i.e. a GW2 API Key).