Requested feature overview description.
I'm wondering if the blacklist could somehow be improved a bit to allow semi-wildcards, i.e. you can add *_tail or tail_* which will be internally saved as the entire list of expanded tags, but presented simply as *_tail or tail_* (for editing purposes). Or maybe have the option to show the entire expanded list as well.

One problem with this is that the available space in a cookie is very limited so it would maybe require it be converted to local storage instead since the easier people can blacklist things, the more they will blacklist.

Another issue would be when to update the blacklist to reflect any new changes to tags (or how to note the user about that it might be needed), since the blacklist is static and does not respect changes to aliases etc., IIRC. However one could always save the last update to the blacklist and update it after x days/weeks if it contains wildcard characters. Otherwise this would be completely up to the user.

Or maybe an easier alternative could simply be to allow non-expanded wildcards in the blacklist, i.e. it would be up to the user to make sure that they have the proper name for their tags and not names that have been aliased away. (FYI this is how I roll in my own app)

Why would it be useful?
For the tagger it may be very useful when there are a lot of subtags for a larger umbrella term and you want to search e.g. piercing -xxx_piercing -yyy_piercing -zzz_piercing ... hence blacklisting *_piercing might be interesting. However if negative wildcard searching is fixed this point is pretty much moot.

For a viewer the case may be similar but there might not be an umbrella term for something (as is the case with tail), so blacklisting tail_* and *_tail can at least catch the ones you need without having to enter them all manually.

What part(s) of the site page(s) are affected?

Blacklist, editing and/or application.

Reference: forum #203053

This would be a really cool and handy idea

+1*

After seeing the lot of userscripts being used on this site, I thought of making a blacklist userscript that would hide out the posts that contain the tags like that, just to reduce the stress on the servers a bit. An even better idea would to add a wildcard feature like this into it.

Looks like I have some R&D to do...

Since cookies are such a hot topic. I'm going to add to the issue: What is the reason for storing it client-side anyway? I mean it's already stored server-side and all it does right now is to use bandwidth (since the cookie is sent back and forth with every request).

Because otherwise I can't really understand why, just injecting it into into the page would work just as good if not better with the added benefit of not requiring neither cookies nor local storage.

Additionally, what are the current events if I e.g. blacklist the aliased tag butt_up which is converted to ass_up, but that is later aliased to hindquarters_up? Is the blacklist system currently capable of handling such a thing?

Nikolaithefur said:
After seeing the lot of userscripts being used on this site, I thought of making a blacklist userscript that would hide out the posts that contain the tags like that, just to reduce the stress on the servers a bit. An even better idea would to add a wildcard feature like this into it.

Looks like I have some R&D to do...

AFAIK, the blacklist is probably fairly light on the servers seeing as the only thing stored and processed server-side is the actual blacklist (except for cookies being sent back and forth all the time), the actual blacklisting is all done client-side. So what you do with your user scripts are not going to influence the server load at all.

Approved. There are some complications about how blacklists work that need to be resolved first, but this is a great idea.

Excellent idea!

This would potentially solve most of the issues in forum #193528 (which you mentioned)

as well as open up new possibilities for black/whitelisting
[relevant specific post link in forum #187706 goes here]