You gave your penis control of the favorites button. That's what happened.

How did that even happen? (No offense, just curious)
Does Lana sponsor this site, do Lana and the admin know each other or is the admin just a really big fan of her?
A lot of my favs have her icon on it, so I guess we have a similar taste xD

Early on, the admin lozertuser must have thought it was cool when famous people visited his site. He might do something nice for them after confirming that it was in fact them.

The first I know of was game reviewer/player LordKat (Jason Pullara) who got his own such icon. It can't be a coincidence that his affiliates are well known on Gelbooru including ThatGuyWithTheGlasses (Probably an alias and promotion for LordKat for all I know) and HopeWithinChaos who has been a moderator on Gelbooru since pretty much the beginning. I don't know for sure but it does seem likely that loozer actually knows these people.

Aside from fellow mod Xalrun and his Gelcom Create.swf comics ( xalrun.wordpress.com/ and gelcom.wordpress.com/ , gelcom.booru.org/index.php?page=post&s=list&tags=all ), Lana Rain was the next artist I know of to be in contact with the admin. She got her own icon for posts that she would favorite the same as LordKat.

More recently, many more artists are coming forward, especially from Patreon. If they wish, they can confirm their artist status with lozer and have a personal banner on posts with their tag.

"We've been looking into searching user favorites for the past year, but it hasn't produced any meaningful results in efficiency, especially as user favorites go over a set number. If we switched to PostgreSQL, from my understanding, it would be possible, but expensive to do. If we maintain using MySQL/MariaDB, it probably won't be."

The most effective way to do this would be with client side code. After inspecting the favorites page with the developer tools in Chrome, I noticed that the tags are present on the DOM. They just aren't displayed. Client side JavaScript can filter them when the user stops typing their tags to filter to. When the filtering is complete, non-matches would have their CSS display set to "none" and matches would have the CSS set to normal display. This would scale linearly with respect to the number of posts a user has favorited, but it shouldn't take too long even for a user with ~5000 favorites.

If the site admin PMs me, I can provide my time to code this.

I decided to go ahead and implement this myself as client side code.

My solution looks like this when installed: imgur.com/a/jl9eG

When the page loads, it now has a text input where users enter the tags they want to filter to separated by a space, exactly how they search for posts already. After 500ms have passed since the last key press, the filter runs. All posts are revealed and then the posts that do not match are hidden. As each filter runs, the DOM elements are iterated over from a cache variable, so the DOM doesn't need to be scanned for each filter, only once as the page loads. This should remain fast even as lots of favorites are added.

JavaScript (ES3): gist.github.com/anonymous/ce6e11f6be5056f23e006ec48c926207
And because it was coded in TypeScript, here's the source code: gist.github.com/anonymous/e7f66ebdcb88a07d82f5f849d87266be

Note that the only dev dependency for the source code is "typescript": "^2.7.2".

To install, ensure that the server sends this JavaScript to the page (or a script tag directing the browser to load the code from a dedicated URL), *after* all favorites have been rendered to the page. Right before the </body> tag is ideal for this.

The code is in an IIFE so it will not interfere with existing client side code for the page.

_________________________________________

For those eager to use this before the site admin implements it, you can copy and paste the contents of the compiled code into your console in your browser's dev tools and hit enter. You'll see the filter input added to the page and the filtering will work. Note that closing the page will cause this to be deactivated until you repeat these steps again.

This would only account for the first page, not their entire favorite collection, correct?

That's correct. In order for this to work for all favorites, they would need to have no pagination for favorites. It would return all favorites on one page.

In terms of server load, it is worth noting that it would receive far fewer requests since they would only need to load one page. I imagine most users browse this site in an "open new tab" fashion, so they would keep the loaded favorites page open while they enjoy their visit.

Or perhaps you could have a "view all favorites on one page" page, which throttled users as you think is appropriate.

The thing is memory usage for users and requests per second for us. If you had over a set amount of images, the memory would skyrocket, requests would flood in, (70K possibly for some users) and be unsustainable. Even at 1K favorites, that's still 1000 requests to our server, which would be seen as a DoS against our box.

Why would adding a favorite to the rendered favorites page constitute a request to the web server? Do you use AJAX to load each favorite individually after the page is rendered by the server and sent to the browser?

Or, are you referring to requests from the web server to the database? If so, why does viewing the favorites page involve running an N+1 query and are you aware that this can be optimized to run as 1 or 2 queries per favorites page visit, regardless of how many favorites a user has?

EDIT:

Ah I believe I see what you're referring to now. The thumbnails come from "simg3.gelbooru.com", so you're worried about all the requests to that server. I assumed this was an object storage service like AWS S3, so I didn't think you were worried about capacity issues there (though perhaps would be worried about cost now that you bring it up).

Would you like me to add to my client side code so that the thumbnails are only loaded if the favorite is viewable in the viewport? This should have the effect of only firing off as many requests to the static image server as are needed to show what the user is currently looking at. And, any future thumbnail load for an image would be cached by the browser as long as the Cache-Control header is set correctly.

To further safe-guard against this pseudo-DoS, you could have the favorites section hidden in the DOM by default (set by server during page render) to be revealed in the DOM if the user has JavaScript enabled. This would prevent users with JavaScript disabled (ex. those visiting with Tor) from short-circuiting this "delay thumbnail load until DOM element visible" feature, causing a pseudo-DoS.

EDIT again:

I just remembered noticing that delay thumbnail load feature in the main browsing section. So it looks like you've already got it implemented. You'd just have to copy/paste that code to the favorites section to apply it to those thumbnails too. So that that point, it's just memory usage that's the concern right? That's understandable, you don't want that 70k favorites user to crash the site. I have an idea to buffer the favorites, sending them to the page (via AJAX) a constant number at a time (could be 1000, 500, 100 at a time, etc). If you get me in touch with your dev I'd be happy to discuss it, since it would involve adding another route and forming new SQL queries. If that dev is you, I'd be happy to take the conversation somewhere better for collaboration and assist with it. :)

That "only loading thumbnails as you scroll to them" is basically infinite scrolling, which is something we're intentionally not implementing. Infinite scrolling is an incredibly annoying feature. I've never used a site with infinite scrolling where I had a better experience than I'd have had if it was paginated.