Skip to main content

August 24

Hi all, hope you're doing well ^^

User database table refactoring

I've moved a lot of the user table columns to the new user_account_status table, and updated all the relevant stored procedures and functions that referenced those columns to point to the new table instead.

Rolling rate limits

A simple rate limit for enabling/disabling the "enable 4K display" global option in user settings has been implemented, just to prevent abusive toggling of it (as it involves performing a bunch of S3 operations). For now the limit is 24 times in 24 hours, which most users are never going to run into. 

This works via a Redis sorted set, in which each time the user enables or disables the setting, a new entry is added to the set, and any entries that are too old are removed. This makes it easy and fast to check if a given action has been performed more than X number of times in a given period.

This system should also be easy to use for other areas that need rate limiting, such as aggressive reblogging or other settings that need to be limited in how often they are updated. As such I've made some new classes and database tables to handle making rolling rate limits with multiple durations.

While thinking of Deserted Chateau's performance, I realised that it was likely best to separate out the information about whether a user has interacted with a given artwork (likes, reblogs etc) from the main gallery search stored procedure. 

Not having it there allows for searches to be cached more efficiently, as otherwise a user who liked or reblogged an artwork wouldn't see their reblog or like on that artwork shown until the cached result expired, which would be very confusing and cause a lot of errors when the user would try to reblog or like the artwork again.

I'm still pondering what other changes might need to be made to improve the performance of the main gallery stored procedure, but ultimately most of it is likely to remain as it is. Other changes would involve difficult result management in the backend; for example, not including artwork categories in the search and filtering them afterwards could theoretically make for better caching, but could require multiple round trips in many cases to get a suitable number of artworks that didn't conflict with the user's filters. 

The only realistic way to try and get useful data for this will be to create datasets of artworks, users, likes and so on that can be set up and torn down from the database for testing purposes, to populate a lot of the joined tables in the gallery SQL procedure to make it do more work. I'll hopefully have created the set up and tear down scripts and done some tests by the next update.

Notification caching changes

I've improved how user notifications are cached, both in the frontend and backend code. The problem was that the count of unread notifications, and the actual notification content, were being cached separately; that leads to weird scenarios where the page could show no new notifications when there are some, and vice versa.

Instead, both entries are cached in the same Redis hash with the same expiry time in the backend, and the frontend caches the server-provided result with a single key per page of notifications, where every page has the same unread notification count.

Display Artwork bookmark controls

I've implemented the 'add to bookmark folder' button in the Display Artwork page, where before it only worked in gallery pages.

Getting it to display properly was a bit of challenge, due to the Display Artwork page layout and the CSS positioning of Tippy tooltips, but it's working now.

Artwork Category changes

I've added a "Flashing Lights" category to the NSFW/sensitive artwork categories, to help users who have epilepsy avoid videos that have flashing lights in them.

I've also implemented a stored procedure to add new artwork categories, as it involves updating several tables (so that each artwork has a default setting for the category, and each user's navigation settings are updated with the new category).

Bug Report pages

I've mostly finished creating the bug report and existing bugs list pages, which are linked to in the error pages when e.g. a page isn't found. I need to polish up the styling on both, but the functionality is done; the last functional bit left to implement is a backend page for admins to manage user bug reports, so they can accept/reject bug reports and change the status of existing ones.

Had a little fun with Font Awesome icons for the existing bugs page, though I'll probably tone down the brightness of the colours later or something.

image.png

image.png

Moderation: plans and considerations

In the time I spent on Deserted Chateau this last two weeks, I spent a lot of it thinking about how to make the moderation system sustainable. There are several things I have in mind for this:

  • Areas like the artwork submission page need clear highlighting and explanations to users, regarding the mandatory requirement to add categories to NSFW or sensitive artworks. This will minimise the number of incorrectly categorised artworks that need to be moderated.

  • The backend moderation pages need to be as easy to use as possible, so that moderating a list of reports or items isn't cumbersome and slow.

  • Artwork display pages need to show categories in an easily viewable way, so that users can effectively report when an artwork has incorrect categories (otherwise, it's hard for them to do).

Standardised Report Modals

I've added report buttons to the gallery feed style display, which also necessitates making the report modal that currently exists on the DisplayArtwork page into something that can be used as a standard across Deserted Chateau. It works in a fairly simple manner, so for the most part this is easy to do, but I need to refactor a bit of the code to ensure it can be easily used in any page.

Bug Fixes

  • Fixed another bug that was causing additional images of an artwork in a gallery to be sized incorrectly in a few cases.

Minor Improvements

Documentation Updates

  • Documented the system for adding shell tooltips to pages, and how they should have their content initialised.

  • Updated the Webserver documentation regarding the procedure for obtaining SSL certificates on Lightsail instances.

  • Documented the new rate limiting system, classes and database tables in the Technical -> Redis section.

  • Made a lot of improvements and additions to the Guide for new art sites section. Updated the SSL/TLS certificate requesting section, the server-side and client-side caching sections and the moderation section.
Back to top