Requested feature overview description.
A blacklist search tag similar in structure to the Rating: tag.
Why would it be useful?
It would allow you to use it with a minus to remove your entire blacklist from the search. It would look like something like this "Female -Blacklist"
What part(s) of the site page(s) are affected?
Just the search bar.

But there’s already a button to toggle the blacklist?

Presumably the benefit would be that the search doesn't return blacklisted images, so certain searches don't end up with a bunch of blank or nearly blank pages. Only example off the top of my head is searching "infantilism" with "diaper" blacklisted

If I remember right, the reason we couldn't have this is because the blacklist is not implemented server-side.

+1 I think it'd be really nice if we could have this, or something like this, I know people have been asking for "tag groups" for a while to make searching/excluding from searches easier. This kinda seems like it'd be a way of implementing such a feature, though I don't know how difficult it'd be in practice.

This simply is not possible, it's been attempted to be suggested multiple times and always ends the exact same way

donovan_dmc said:
This simply is not possible, it's been attempted to be suggested multiple times and always ends the exact same way

And again, like stated in those topics, someone can do this client-side with a custom client. :)

alphamule said:
And again, like stated in those topics, someone can do this client-side with a custom client. :)

Not... really? Blacklisting is entirely clientside, unless you have a clone of the site you're still skipping over posts

donovan_dmc said:
Not... really? Blacklisting is entirely clientside, unless you have a clone of the site you're still skipping over posts

I think all alphamule meant is a client that could skip over posts without so much trouble. The raw site's next/previous links don't skip over blacklisted posts, while a custom client can absolutely do that. That would be a nice feature for RE621 to have, actually.

scth said:
I think all alphamule meant is a client that could skip over posts without so much trouble. The raw site's next/previous links don't skip over blacklisted posts, while a custom client can absolutely do that. That would be a nice feature for RE621 to have, actually.

I think it would be quite jarring for it to just skip through pages since the client has no idea what the full results of the search were, so it doesn't know what posts were blacklisted
While it could store those results you'll have issues if you ever go to any different search or via various other things

donovan_dmc said:
This simply is not possible, it's been attempted to be suggested multiple times and always ends the exact same way

I mean, "not possible" is a bit strong. Possible? Definitely, just put the blacklist logic on the server. Worth it? Yeah likely not.

Maybe the client could calculate the most blacklisted tags (i.e. say 5) and send that as a hint to the server to silently add a -thattag and refresh the page counter.

voxem said:
I mean, "not possible" is a bit strong. Possible? Definitely, just put the blacklist logic on the server.

"not possible" is being used for right now, so yes, not possible. Either way the logic isn't being moved onto the server any time soon (if ever, which is also very unlikely), so yet again, not possible.

donovan_dmc said:
"not possible" is being used for right now, so yes, not possible. Either way the logic isn't being moved onto the server any time soon (if ever, which is also very unlikely), so yet again, not possible.

Wasn't the entire point of Danbooru-based designs, to use less resources server-side? It makes sense not to do this server-side, especially in that context.

voxem said:
I mean, "not possible" is a bit strong. Possible? Definitely, just put the blacklist logic on the server. Worth it? Yeah likely not.

Maybe the client could calculate the most blacklisted tags (i.e. say 5) and send that as a hint to the server to silently add a -thattag and refresh the page counter.

For a more technical explanation:

Keep in mind that blacklists aren't single tags, but each line is itself a complex query with its own exclusions and or-logic. There's no good way to optimize such queries in SQL, you'd have to instruct the database to search for all posts that match the criteria, then have the database check and see if any sub-query (corresponding to a line in the blacklist) matched and, if so, exclude the matching posts. This would turn what is a linear-timed query into a high exponential-time query, and would chew through DB read operations like they were candy. With higher load on the database comes higher monetary costs, as SQL databases aren't cheap to run and don't tend to easily scale across multiple servers as well, and it's pretty clear that keeping costs under control is a major factor in running E621.

And sure, one could argue that it could be done in server logic rather than DB logic, but now you're having to replicate the DB query logic in software, since as I said, each line in a blacklist is a full-fledged search query. You'd be having to maintain two branches of the same code, each with its own set of bugs. And when you end up blacklisting posts, that would cost more trips to the database in an attempt to fill out the page with posts. And it'd be even worse performance than the DB version, in exchange for being slightly more scalable.

So, given both of those and my own experience, I don't expect that we'll see this sort of functionality anytime soon. It's not about whether it's possible to code (it is), it's about whether it's cost effective to run (it's not).