It’s been quite a while since my last post, even longer since my last progress post. I think it’s time to continue this again and keep a record of the things I’ve been working on. In the time I’ve been away I’ve mostly been maintaining Caturra and also doing a bit of work on Trinity. A lot has happened in this past week though.

Trinity Website announcement

I’ve mentioned before that we were going to have a big update for Trinity, and it’s probably time to post about it now. It’ll show up a lot in my progress posts now so here we go.

Trinity is finally getting a website, it’s been requested for years and it’s finally happening. Miquel who has helped me before for the TUYUcord leaderboard website is currently working on a design while I’m working on moving our legacy API to the new website. That also means I don’t have anything to show you yet, but we’re working on it!

My main priority right now is getting the API ready so Trinity can use this API instead of our legacy API. In order to do that I submitted a library PR and 9 PRs implementing more endpoints. Most features that only require reading information from the database are working right now, with these PRs merged a lot of the add functionality will also work. Hopefully either next week or the week after I’ll be able to run the Discord client through this new API.

Major optimization in Caturra API

So unfortunately when this post is going live this optimization won’t have been applied yet on production, but it should be a major optimization. While I was checking my emails I noticed that some performance issues got opened on Laravel Nightwatch (exception and performance tracker). The ping endpoint would sometimes take nearly 2 seconds to finish a request which is obviously not good.

I see that there are a lot of DB queries caused by caching (rate limit checks) but these shouldn’t take this long. Unfortunately due to some unexpected server moving from our hosting providers we’ve got the database in a different country then the actual website. Just moving the data to the same server isn’t as easy as it sounds due to our database replication setup.

Instead, we’re going to be doing our caching in redis now which will be local on the website server. This has already been applied on cutting edge but this hasn’t been put in place on production yet, so coming soon!

Massbanning in TUYUcord

Mass banning users sounds really bad but this is one of the rare situations where we need this feature. Unfortunately on TUYUcord we’ve experienced some bot raids, and recently we got hit by quite a big one (over 100 accounts) for our small mod team. Thankfully the online mods were able to ban all the raiders, but it’s still a situation that we could’ve dealt better with.

To address this problem I implemented a mass banning system that allows a moderator to give a list of user ids, either in a csv format or with new lines and then those users will all be banned. There’s obviously a problem where a hacked staff member shouldn’t be able to execute mass bans through our own bot, that would be very problematic. Or a rogue moderator would also be a problem.

Because of this there is a verification step, once you’ve requested a mass ban a different moderator has to approve the mass ban. If the mass ban is denied nothing happens, only when it gets approved will the users be banned. Hopefully this will make dealing with raids easier and faster in the future.

Quick fire changes

• Did some Dutch translations for Caturra, this hasn’t been released yet though
• Put some more Trinity infrastructure tasks on our planning issue on GitHub