Topic: "-blacklisted" as a tag?

Full disclosure, I don't know if somebody has already written about this.

The blacklist feature on this site is very useful. However, one thing that continuously annoys me is that, when activated, the blacklist only hides content superficially, meaning that the posts themselves are still visible when you click your way through, just that the imagery isn't displayed, meaning that when you're browsing you're sometimes having to click though multiple "empty" pages in sequence.
That got me thinking, could you perhaps add "-blacklisted" as a tag for the search bar, so that the posts in question are not displayed at all? Obviously, this would only work when logged in.

Unfortunately, the blacklist is a filter on your pipeline to the database, not on the database itself. You can append a "-unwanted_tag" to your individual searches but that's the closest you get.

The blacklist is entirely clientside and no method exists to apply it to searches on the server, the sheer performance impact that would have on the site would probably kill it overnight

This would also almost certainly blow past the maximum allowed number of terms in a post search (that being 40), consequently destroying performance. We could theoretically try to remove entries after the initial search, but that would

• double the load on the server (functionally making 2 searches, 1 in an unoptimized manner)
• require a behemoth of extra (& inherently redundant) code to properly filter & output the results
• disallow toggling blacklist filters on & off in real time
• add a ton of extra complexity to account for currently-disabled filters at all

Put simply, this would functionally require completely rewriting almost all of the post search code (from what's sent to the server in the request, to the search processing) & probably require the server (& not the browser) to track what filters are deactivated (making extra requests to keep it up to date), all to alleviate a minor annoyance. I'm not saying I wouldn't want something like this (that's part of why I looked into the site's code to begin with), but it's simply infeasible, both in terms of real-time server resources to support & dev time resources to implement.

The site is open source, so anyone who's interested can get the code from our GitHub page & try to implement & profile it themselves, but I don't think we'd have the time to take a stab at this ourselves. That said, that's the same situation grouped searches were in when I came along, so someone could always come along & give it a shot (although whether we'd consider it worth the consequences is another matter entirely), but it's unlikely to come from us, especially with how time-consuming & likely futile it would be to even attempt to implement.

aacafah said:
This would also almost certainly blow past the maximum allowed number of terms in a post search (that being 40), consequently destroying performance. We could theoretically try to remove entries after the initial search, but that would

• double the load on the server (functionally making 2 searches, 1 in an unoptimized manner)
• require a behemoth of extra (& inherently redundant) code to properly filter & output the results
• disallow toggling blacklist filters on & off in real time
• add a ton of extra complexity to account for currently-disabled filters at all

Put simply, this would functionally require completely rewriting almost all of the post search code (from what's sent to the server in the request, to the search processing) & probably require the server (& not the browser) to track what filters are deactivated (making extra requests to keep it up to date), all to alleviate a minor annoyance. I'm not saying I wouldn't want something like this (that's part of why I looked into the site's code to begin with), but it's simply infeasible, both in terms of real-time server resources to support & dev time resources to implement.

The site is open source, so anyone who's interested can get the code from our GitHub page & try to implement & profile it themselves, but I don't think we'd have the time to take a stab at this ourselves. That said, that's the same situation grouped searches were in when I came along, so someone could always come along & give it a shot (although whether we'd consider it worth the consequences is another matter entirely), but it's unlikely to come from us, especially with how time-consuming & likely futile it would be to even attempt to implement.

Alright, I guess that would represent too many conditions for the system to handle at once, especially with all the sub-tagging factored in. I just thought since the system is able to black out blacklisted posts in the browsing page, perhaps it could do the same when you're clicking though the posts (skipping posts for instance). But I don't have any dev experience so I don't really have a handle on the complexities that would be involved. Thank you for taking the time to answer.

Here's my stab at creating something that emulates what I'm looking for on the user side:

https://greasyfork.org/en/scripts/568407-e621-skip-blacklisted-posts