EpsilonBot - Moderation Update

  • The most recent update to EpsilonBot is one that has been needed for a while now but that I've been procrastinating on since it takes a while to write and wasn't very fun to implement either. But now, finally, EpsilonBot has functional moderation features that can be used by staff.

    Here's the rundown of how it works:

    Permission Levels

    EpsilonBot now has three permission levels. You can use the `test command to check your permission level.

    0: This is the default permission level that all players have. It can use all of EpsilonBot's features that are intended for public use.

    1: This is the permission level assigned to staff. It allows you to use every single moderation command as well as `restart. The only command that currently cannot be used at this permission level is `stop.

    If you are registered on EpsilonBot's staff list, it will give you this permission level. People that are registered as staff have the permission to add/remove other staff members. You can even remove yourself, although I wouldn't recommend doing that since you won't be able to add yourself back.

    2: This permission level can use every command on EpsilonBot. It is the maximum permission level.

    This permission level is given to anyone that is listed as "trusted" in the bot's config file. No ingame commands can add or remove someone's trusted status. Even if they are removed from the staff list, they will not lose their permission level. The only way to change who is trusted is for me to manually edit config.yml and restart the bot.

    Currently, the people I have listed as trusted are Tizz, Video, and myself. I haven't changed this since before the moderation update, and this was mostly just a way to make sure someone could moderate or stop my bot in an emergency if I wasn't around, so this list may be subject to change.

    Still, don't really see any problems with it at the moment so I've left it as is.

    New Commands

    `addstaff <username> - This command adds a staff member with the specified username. The bot then queries for the player's Minecraft profile through ashcon.app's api and adds their UUID to the staff list if found.

    `removestaff <username> - Same as addstaff, but removes the player from the staff list.

    `liststaff - List all staff members' current usernames by querying for them on ashcon.app's api.

    `blacklist <username> - Adds a player to EpsilonBot's blacklist. Epsilonbot will not respond to commands associated with their uuid.

    `unblacklist <username> - Removes a player from EpsilonBot's blacklist.

    Other Comments

    It was suggested that I have EpsilonBot use /saconfig, list to update its staff list automatically, but I won't be doing this for now for a couple reasons. For one, EpsilonBot would be less portable that way, because currently it is capable of running on servers other than TF (for example, Kaboom), even though I currently only run it on TF. Additionally, however, I just want to have finer control over the staff list, and if anything goes wrong with doing /saconfig list it might just delete the entire staff list by accident. That can be prevented but it's not worth the effort to develop and make secure with everything else considered.

    Also, note that blacklist, staff, and in fact the entire permissions system is based on the player uuid sent with every chat message packet, so none of it will work from discord. Since players can use nicks both ingame and in discord, UUID is the only secure way I can think of for handling things related to blacklist or permissions. Thus, staff cannot use restricted commands from discord, and people on discord cannot be blacklisted. This is not ideal, but it is what it is.

    One final note: this is all broken in the current versions of spigot and paper in 1.19. As you may know, the current versions completely break chat message signatures, and the reason for this seems, based on what I've experienced while developing a client, is that they don't even send chat messages through the chat message packet. Thus, since they are sent as game messages rather than chat messages, not only is the signature not attached but also the uuid. Thus, so long as paper or spigot does not fix this, the permission system will not work in 1.19. Correct me if I'm mistaken about this, though, since I only know this based on my experience while developing HClient.