Enhance franzbot

[kalilistic]

Franz has done great with Franzbot. According to their own comments in the past, the code could use a rewrite to be easier to maintain and support it's growing responsibilities.

[goaaats]

XIVLauncher can also generate a zip file with all logs and a JSON blob with additional context by clicking its logo.

It would be nice to take advantage of that.

[karashiiro]

The scale of a Franzbot rewrite can't be understated, someone would need to put some serious planning into architecting something maintainable and refactoring everything into that.

[reiichi001]

For the most part, the bulk of Franzbot's logic for XIVLauncher/Dalamud/Plugins can be located in two sections:

1. Per-server FAQs, which are loaded as modules
2. the messageCreate.js event handler.

Right now, I feel like FAQs are in a mostly good position. I'd like to eventually switch out the text command for a slash command, but I've been having some difficulty coming up with a solution that would give us per-server config that can be reliably deployed without showing up on other servers.

In terms of messageCreate, I'd like to also migrate it to using modules so that we can better tailor which code is executed based on server ID instead of a mess of if-else statements. Perhaps we could split off the log parsing into a shared module, as I know it's now being used for a webservice too. Making this handle the full troubleshooting pack would be pretty easy, as all the files we've come to expect are still there, they'd just need to be unzipped and processed as usual.

I'd previously considered a ticket command, which is partially implemented, but never got around to fixing my json serializing/deserializing for it. It really only needs to know a few things:

• which category should be used to create the tickets and sync permissions before granting user access?
• is the ticket open or closed? (Eventually, delete closed tickets, or allow them to be deleted/re-opened)
• if the ticket is reopened, re-grant any other people who were added into it aside from support users and the user who made it.

If we want some really wishful thinking, we could also implement searching the suggestions repo and perhaps even posting to it on behalf of users instead of having to scour the suggestions channel in discord.

As Franzbot has sort of grown as a tailored bot for specific servers, I would like to keep that functionality there, or we could always split it into two bots, but in the latter case, there would be setup hurdles like getting it reinvited everywhere it needs to be. Many of the FC-centric commands are just joke commands/toys and could be easily disabled as needed. Some of them could also possibly be extended to work in our discord, like the tosagree command.

[ArcaneDisgea]

Getting it re-invited is no biggie in my opinion. I will admit I'm not too across all the servers it's in, I only know of Penumbra and Goatplace so that doesn't seem like a hefty task.

messageCreate.js is massive and was very daunting when I was pulling parts out for a PoC of parsing logs in browser. I think the first major hurdle to dev and maintenance would be to take incoming data from messageCreate and pass it to a messageHandler of sorts that can have and use modules to parse for logs, badwords, etc. This would make it very easy to add more triggers for various messages.

The ticket command would also be a great idea and I think it should utilize threads since they are auto-archiving and therefor can be consider auto-closing when a ticket becomes stale. A message is all it takes to re-open it and the bot can mention a role to pull any support staff into it.

The suggestions repo stuff would be difficult without users following a very strict format but we could have franzbot delete posts that don't follow that format and tell the user the correct format to use.

I'm going to address the elephant in the room as well and point out franzbot's stateless nature and inquire whether this is something we want to change or keep. Being stateless is nice because we can just spin it up and be fine with little to no tinkering but giving him state could enable us to have dashboards that let more than just franz manage the bots modules for their server.

[karashiiro]

Franzbot isn't actually stateless, is it? I saw that it had a JSON filesystem DB thing set up. I do think that at this scale, Franzbot would benefit from being converted into a proper MVC app with a management dashboard for adding triggers and whatnot. Alternatively, something backed by a GH repo could work, so long as someone has a reasonable format for describing triggers that way.

[reiichi001]

Right now, Franzbot services Meteor, Goatplace, XOM, Penumbra, and a couple personal servers (FC, Testing). There could be a day it comes to Sapphire too. The issue is that I don't have invite privileges to all of those, and I tend to be a stickler for bot permissions, as I generally want to keep them as minimal as possible. Franzbot could use more checks to see if it has permission to do functions like say, delete a message. (Some tooling to be able to reuse that easily would be nice)

Franzbot is largely stateless, barring running memory for things like cooldown timers.

The simple-json-db stuff is largely experimental and not being used for much of anything. It does a couple of things to wrap config, but it's not actually handling state of any kind currently. My goal would be to eventually migrate some hardcoded config items over to per-server configs, like suggestion watch channels, which roles get to bypass triggers, which roles can use its admin commands, etc.

I'm not averse to migrating triggers and FAQs over to a dashboard, but then it would become a much larger project and I don't think it quite needs a fully fleshed out webinterface. I'll be the first to admit that I'm not very familiar with MVC or patterns in general, which could make code maintenance more difficult.

The current method of PRing a faq file is generally pretty easy even for non-programmers and allows for customizing if/as needed. With the more recent addition of pushing to GCP on merge, I can effectively administrate it remotely aside from config file changes, some of which would be nice to switch over to something a bit more stateful, even if that's just get/set from config so it loads the last known state, like for the newpatch trigger. As system where a user could just drop in new triggers or update them and messageCreate would pull from there would likely be plenty for management needs, similar to the existing FAQ system. What makes Franzbot nice is that it's near-immediate to get up and running and can be restarted without worry. Because its moving parts are basically all just the application, it's also relatively easy to migrate to another server. Dashboards could complicate that.

[ArcaneDisgea]

I'm fine not having dashboards and maintaining it's stateless stance to be clear. I just figured I'd throw it out there since if we are already rewriting it this is the perfect opportunity to begin to include such things.

[kalilistic]

After discussion in discord, agreed with Franz/Arc/Others that this doesn't really need a DIP. Franzbot is not goatcorp specific and this can be handled through separate discussions or issues on the franzbot discord.