Project:Discord Bot Improvements

This is a general TODO area for improvements to the bot situation on DisNCord. Contact User:Kraaabs (Krabs#0571 on Discord) with comments/concerns/suggestions!

Better Discord logging

Status: The bot is currently in development, and a prototype is nearing completion.

As it stands, the wiki discussion logs (such as Lotus Notes and Taligent Shenanigans Log or SoylentNews History Log) are manually copied and pasted before being either run through a script to convert them to WikiText, or manually formatted by hand. This approach has a few drawbacks:

1. Things are easily missed
   1. Discord is... inconsistent when copy pasting large amounts of messages. The infinite scroll implementation in the client is fairly aggressive, and it leads to messages getting booted from the selection buffer sometimes, without anyone noticing.
2. Manual labour
   1. The process right now is mostly manual. This gets tedious when there are large logs to be converted, or more than one log at once.
   2. Logs with images (such as Lotus Notes and Taligent Shenanigans Log) need to have their images manually downloaded, uploaded to the wiki, and embedded. That's a pain.
3. Formatting
   1. Copy pasting logs isn't perfect. There isn't enough metadata to properly automate formatting of things like link embeds.

User:Kraaabs has written (most of) a Discord bot that can record messages to a few formats, including WikiText. After some cleanup and feature additions, it should be well suited to the task.

Raconteur repository on GitLab

Raconteur TODO

1. Better document the code, and open the repository up to the public DONE! (sorta. docs aren't there yet)
2. See about using user permissions for the bot, rather than any moderator permissions DONE! (actually, the retroactive logging shouldn't require any special permissions. proactive logging needs some permissions to set up, but not to archive/create archival threads)
3. Flesh out retroactive logging (in addition to the proactive logging already implemented) DONE! (at least to the level of the proactive logging)
4. Grab embeds for messages as well (maybe embed them in the JSON log format as base64?) DONE! (although I'm on the fence about including them in the JSON output. Boy howdy, base64 can get LARGE)
5. Containerize it! (see below)
6. MediaWiki companion bot to upload images/automatically create pages (it seems there are mature Python bindings for the MediaWiki API) DONE! (I had to write my own MediaWiki API bindings. The bot can now create pages, and image uploads aren't far off.)
7. Whatever else I forgot (I'm sure I'll add more as I go)

Modmail/Ticketing

Status: Tickets is currently being trialled on the main DisNCord server (good success so far)

Currently, DisNCord doesn't have any formal modmail or ticketing for moderator concerns. Specific concerns are handled by direct messaging moderators, and communicating in the #mod-discussion channel, with User:NCommander having the final say. This may not scale well as the server continues to grow, so a proper modmail or ticketing system would be beneficial. If you have other suggestions for ticketing bots, or experience using any of these, contact User:Kraaabs (Krabs#0571 on Discord) with your thoughts!

Current proposed candidates:

discord-mod-mail

Pros

• Extremely simple codebase
• Sirocyl has experience with it
• Already dockerized
• Looks easily hackable if needed

Cons

• Uses old-style prefixed bot commands (not necessarily a con per-se)
• No formal role-locking -- relies on channel visibility

Ticket Tool

Pros

• Appears very robust feature-wise
• Comes with a handy dashboard -- but it's discord integrated
• Seemingly scales well

Cons

• The free version is rate-limited (although I don't think we'll hit the limit)
• Features such as DM support are locked behind a paywall
• UX is somewhat inconsistent and awkward
• Piles up closed tickets as channels with no real archival
• GDPR clause just says "contact us" with no other info

Tickets

Pros

• Similar feature set to Ticket Tool
• Allows multiple support teams
• Similar to Ticket Tool, used on many many servers already
• Very polished interface
• Deletes ticket channels when tickets are closed, but archives them in a thread for later viewing
• Allows for the creation of custom forms and panels for ticket creation!

Cons

• Again, some features are paywalled (but nothing super essential...)
• GDPR is handled through a discord server, which is... odd

Bot Infrastructure

Status: The Wiki and Fediverse servers are currently being moved. Afterwards, further discussion of bot hosting will be done.

The thing about Discord bots is that you need to host them, of course. Ideally, for ease of management, all bots would be hosted on Restless Systems infrastructure, using Docker containers.

TODO

1. Do we need a separate VPS for bots? Or will we host on the wiki infra?
2. Are all the bots we want to host Dockerized already? Or do we need to make our own containers?
3. How will we manage the containers? Manually, or with something like K8s?
   1. Actually, podman could work too, and it's a bit simpler...
4. If we want to do auto-updates (we probably do) how will we accomplish this?
   1. User:NCommander had suggested to me that we could use GitHub/GitLab actions. If we go this route, we would likely have to mirror any bots we're using in our own GitHub/GitLab project. This could pose a problem with the proprietary bots though...
      1. Although, we don't actually need to self host those. In fact, I don't think we can (duh. coffee finally kicked in I guess)
      2. Also: to get this working we'd need to set up that Git{Lab|Hub} project in the first place
5. For consistency's sake, are we going to re-containerize everything to use the same OS inside the containers, if they aren't already? (I doubt all of the bot authors involved are using the same OS)
   1. Despite all of the bots probably being written in different languages using different API wrappers, as much consistency as possible would be nice... Although that's mostly just OCD Sarah talking
6. Finally, what DO we want to host? Should we take this opportunity to self host things like YAGPDB or PK alongside Raconteur and any potential ticketing bot (if we go with a self hosted one)?