Deprecate NotificationBlock... maybe?

[marcustyphoon]

On the one hand, NotificationBlock is a duplicate of a built-in Tumblr feature (only available on web right now, but so is XKit, of course). Users who have used it before should be able to keep it, but for users who have not, this is just confusing (see #1173). The new script deprecation feature is perfect for this.

On the other hand—as Cyle pointed out publicly in a post that I am currently looking for so that I can link it here—the built-in feature has significant differences from the XKit script, and users who want the XKit behavior would benefit from being able to use it.

• The native feature blocks notifications starting now, and there is no way to see blocked ("muted") notifications.
• The XKit script blocks notifications retroactively and starting now, and when a post's notifications are unblocked, when the script is toggled off, or when you are on mobile, you can see hidden notifications.

Ideally(from a functionality standpoint), one feature would allow the user to select whether notifications are hidden retroactively (if your post already went viral, "muting" future notifications doesn't help you see what notes you got on your other posts), would allow you to see the notifications that it hid somewhere, and would correctly affect the notification count indicator on the activity button. Practically, I don't think the native feature, our script, or even a combination of the two or an integration between the two can get anywhere close to this.

This is somewhat similar to the "should XKit Rewritten have blacklist" discussion: the answer there (as I understand it) was "no; even though there are significant limitations on the native filtering feature, it exists, it has some benefits we can't reproduce, it's good enough, and by pushing enthusiasts to use it instead of implementing an alternative we are hopefully increasing the motivation for Staff to improve it."

(Okay, I made that last one up, and the main problem that we all have with it—only having exact match on tags—has never been indicated by Staff to be something anyone is looking into. So maybe that doesn't work.)

Anyway, that logic would indicate that we probably should deprecate NotificationBlock. I have more mixed feelings about it than that, though.

If Staff made the notification mute feature retroactive and reversible, I would change my lean to "yes."

[marcustyphoon]

The post in question (thanks, python script; thanks for nothing, native search :D)

yes, that's how it works:

• activity and push notifications are muted starting when you hit mute and for the time period selected
• during that time, activity won't be created, and pushes won't be sent, about that post
• it's not retroactive; it doesn't remove activity or pushes from before the mute action happened
• the activity and pushes don't come back if you unmute or the temporary mute ends; those events simply weren't recorded in your activity
• all activity (likes, reblogs, replies, etc) are still in the notes on the post, however, if you want to see what's happening while it's muted for you
• definitely keep the xkit extension if you want to totally wipe activity for a post forwards and backwards

[AprilSylph]

no; even though there are significant limitations on the native filtering feature, it exists, it has some benefits we can't reproduce, it's good enough

I think the difference here is that actually, native filtering doesn't have "significant" limitations, at least IMO. The main difference in my eyes is a lack of wildcard filtering, which I believe was classified as an advanced feature in XKit 7. Do we want to build a keyword filtering feature just for that? How many people would care for the amount of effort that would require?

(I maintain that content filtering ignoring tags is a bug; I have no idea how it's not fixed yet.)

The NotificationBlock situation is very different because the featureset is fundamentally different; muting and blocking notifications do two very different things, even if blocking gives the illusion of also muting.

I think deprecation should be reserved for when we want to push people to use the equivalent native feature instead. Notification muting isn't yet in a spot for me to, in good faith, call it a replacement for NotificationBlock. (I wouldn't have counted post filtering as a replacement for Blacklist in its initial form either, since it was just tag filtering, which is fundamentally different from Blacklist's featureset.)

[marcustyphoon]

Fully agreed on this.

[marcustyphoon]

(I maintain that content filtering ignoring tags is a bug; I have no idea how it's not fixed yet.)

That's what I mean re: "significant." Content filtering is keyword search, not exact match; if that's a bug and if that gets fixed we're in business. It's never been confirmed as one, hence why I'm forced to consider it a limitation.

[marcustyphoon]

(If this is not a bug, and the feature is working as intended, I would have to answer a "how many people would care" question with "literally everyone who uses the content filtering feature, I mean not literally, but come on; no one can be expected to list every possible variation on "tw:" and "cw:" and etc for anything they want to filter in the tags; I refuse to believe that any reasonable person would consider that functional." But we both agree on the correct solution for this: tag filtering is for exact tags, post content filtering is for words, and tags are obviously part of post content.)