Bug overview: I have added "downvotes:theoriginal" to my black-list and the downvoted items are still showing
Parts of site effected: blacklist, search results
Expected behaviour: downvoted items should be excluded from all searches
Actual behaviour: downvoted items are still showing
Time: n/a
Can it be reproduced: yes
Steps taken: down-vote item, blacklist "downvotes:theoriginal", search, confirm item is still visible
Other error messages: none

Is there any reason why your normal text is bold, but what is normally supposed to be bold isn't?

It's not a bug, you're using the wrong line in your blacklist.
It should be:
voteddown:theoriginal

There is no support for these meta tags in the blacklist. It isn't a bug. It's also too expensive to have as a feature.

KiraNoot said:
It's also too expensive to have as a feature.

I take it it's now also impossible to see another users downvoted items?

Peekaboo said:
It's not a bug, you're using the wrong line in your blacklist.
It should be:
voteddown:theoriginal

Ill try that but when I search "downvotes:theoriginal" the items that I've downvoted show up.

KiraNoot said:
There is no support for these meta tags in the blacklist. It isn't a bug. It's also too expensive to have as a feature.

ok but if I can search for my downvotes how is that any different or less expensive than blacklisting? Honest question... my programming experience is minimal.

The syntax is voteddown:user. But it won't work for the reason Kira said.

I wanted votedup:user to work so I could blacklist images I've already voted on.

Peekaboo said:
I take it it's now also impossible to see another users downvoted items?

Nope, that was privacy related. You couldn't see votes, so it was just changed to match the rest of the interface.

Moving back to expensive and such, it's expensive because it means loading a complete list of your post votes each time you load a page. This is expensive and slow to do. Same reason that you can't blacklist by favorites. At least when you search for it, it's something you explicitly asked for, not an implicit background thing, and limited to only one area of the site. It's also already noticeably slow in the search area.

^ Can't you cache that client-side and get it down to say 'loading a last-downvote-time timestamp each time you load a page, and reloading the full list only if that timestamp is newer than the cached timestamp'?

(same question applies to blacklisting by favorites)

EDIT: Obviously this would add a little load on the client side (parsing data from localStorage -- probably using split() ), but AFAICS that could be avoided in most cases by only parsing it the first time a blacklist item that needs it was encountered, not unconditionally.

savageorange said:
^ Can't you cache that client-side and get it down to say 'loading a last-downvote-time timestamp each time you load a page, and reloading the full list only if that timestamp is newer than the cached timestamp'?

(same question applies to blacklisting by favorites)

EDIT: Obviously this would add a little load on the client side (parsing data from localStorage -- probably using split() ), but AFAICS that could be avoided in most cases by only parsing it the first time a blacklist item that needs it was encountered, not unconditionally.

Yes, but I'm not convinced that it's a good investment of time. I tend to rate features based on their risk factors. This one has a larger than average number of risk factors. It has high data retrieval cost, and it touches the blacklist in non-trivial ways(this is my nightmare), I already know it isn't very efficient, and it adds base load to the system that doesn't need any additional base load. The cache hit rate is going to be fairly low on this one, because favorites and votes change on a pretty regular basis, and if you're using the feature, you're more likely to be changing votes and or favorites. Finally the offered improvement is fairly small.

All of that factors into why I really don't want to commit to offering it.

KiraNoot said:
The cache hit rate is going to be fairly low on this one, because favorites and votes change on a pretty regular basis, and if you're using the feature, you're more likely to be changing votes and or favorites.

???

I would think the cache hit rate could be extremely high (basically only a miss if you fav/upvote something on a different device or via API), since adding a fav/upvote is a action initiated by the client that could update the cache itself.

I agree with your other points.

I forget, did Sets count as meta tags or no?

I found my own solution to the original concern posted. the search bar works very similar to google search. if you do not want to see something in a search but blacklisting isnt an option all you have to do is put "-" in front of the tag that you dont want. I put "-downvotes:username" in the search bar and it works fine. Its unfortunate that blacklisting our downvotes doesnt work but this is a very easy workaround. "-voteddown:username" also works.