Mastodon.social just changed how DM notifications work, and we must add a new feature or some content may be hidden

mcclure commented 5 months ago

Detailed description

The server-side filtering Mastodon does for DMs has suddenly changed. Mastodon.social has already deployed the new version of the feature right now, and other Mastodon-Ruby servers will pick up the new feature when 4.3.0 ships. The new server-side feature requires Tusky to implement one or more client-side features.

Previously, Mastodon had a setting "Block direct messages from accounts you don't follow" in the Preferences tab. When this setting was checked, DMs from non-followed accounts were silently hidden (in other words, it acted like "Mute", not "Block").

As of two weeks ago, mastodon.social changed this. I'm not aware of any announcement of this outside of the pull request and I discovered it by accident this morning.

There is now a large bar at the top of the notification filters pane (not the preferences*), listing various options that put a notification into "filtered notification" state:

The last of these options, "Filter out notifications from… unsolicited private mentions", is on by default for new users. Actually that's not true, it's on by default for everyone, but according to Claire from Mastodon that was a bug so apparently soon it will be ratcheted back down and only new users (and users who specifically chose to have the flag on) will have it on.

When these "filter" options are engaged, if a "filtered" post is received, it will look like this:

A "N notifications filtered" box appears at the top of the notification column. When clicked, a new column opens showing each user who has sent you filtered notifications. If you click on a username, it opens a third column showing just the notifications from the user in question (screenshot). To make the "N notifications filtered" box go away, you must click the "Dismiss" or "Accept" button next to each of the listed users.

There is a problem: This new feature is server-side, and according to Claire from Mastodon

both the old thing and the new thing are performed server-side, clients that don't support the new thing will just not show you the “Filtered notifications” prompt and won't let you access the filtered notifications.

In summary, there is a new feature that is on by default for some users, and unless Tusky proactively adds support for this feature, this feature will hide content from Tusky users in such a way they cannot know content is being hidden, and cannot turn the feature off, unless they go to the website.

Expected behavior

The new feature is only partially documented (according to @renchap Mastodon has "an internal ticket" to add documentation) but consists of four new endpoints; a list of "notification requests" (it appears to be poll only); a RPC to accept a notification request; an RPC to reject a notification requests; and an RPC to change the server-side notification-filter "policy" (the four checkboxes above, I assume).

I think Tusky 25 should, at minimum, contain a GUI frontend for notifications/policy. As far as I know we have no checkbox for the old "Mute direct messages from people you don't follow" setting, so this is new UI. I would put this in "Account Preferences" (Mastodon puts it in the notification filters box, but I don't think this is practical on mobile.)

I think Tusky 26 should contain full support for displaying, approving, and dismissing (denying) the notification requests. (Earlier would also be nice, but it is a somewhat large feature and 26 is not far away, so maybe we should not rush it.) I think we can mostly reuse the Follow Notifications UI for this, but I think we should also add a "⋮" menu option for "deny all" (possibly this would be good in Follow Notifications as well) because [in my opinion requiring individually clicking on every request, as the Mastodon Web UI requires, would be bad if a user is being targeted for harassment.

As a stopgap before Tusky 25, I think our official Mastodon account should make a post about the new feature, notifying users that the feature may be on for them and showing how to disable it in the web UI.

Steps to reproduce the problem

n/a

Debug information

n/a

connyduck commented 5 months ago

I'll finish the notification refactoring and then look into this.

connyduck commented 3 months ago

I'd like to implement this feature, how should we integrate it into our UI?

mcclure commented 3 months ago

@connyduck I have been trying to keep up with mastodon/mastodon about this, this is the most recent version they posted (not merged and "possibly incomplete" but you can see the new spec additions in the diff):

https://github.com/mastodon/documentation/pull/1447

I propose that under "Account Preferences" we split "Filters" into two entries, "Post Filters" and "Notification Filters"

Under the Notification Filters subpane we should have four checkboxes corresponding to "People you don't follow', "people not following you", "new accounts", "unsolicited private mentions".

If we can put "filter out notifications from" above the checkboxes, and smalltext under the checkboxes explaining each of the four different settings (as some of them describe complex concepts!) that would be ideal.

I think I said at one point I could attempt to make a UI mockup but work has been busy. Would it still help if I attempted this or does my description make sense?

connyduck commented 3 months ago

Basically like the Mastodon Webinterface?

We can definitely do this.

It will not work with older Mastodon versions though, should we 1) Wait with releasing that until after the Mastodon release? (Thats how we previously handled such situations) 2) Check the server version and disable the feature if below 4.3?

Since we will also have other filters for notifications in the notifications tab directly, can we do something to make this less confusing for users? Maybe put all notifications filter settings into one view and open it from both the notifications tab and the account preferences?

mcclure commented 3 months ago

Can't we check for the presence of the /api/v1/notifications/policy endpoint? It seems to be unique to this feature.

I don't think it would be a good idea to try to incorporate this into the notifications tab filter pane popup, unfortunately, there's just not enough room to fit it in cleanly. I for one would be very unhappy if we moved the filter popup into its own pane instead of a popup because I like to use the popup for very quick changes (I even have a personal UI hack I use to make it faster).

However, one option might be, in the notifications tab ⋮ menu, a "Server side filters" or "Server filters" item, next to the existing "Filters" item, going to the Account Preferences pane.

(We could also maybe rename "Filters" to "Kinds", or leave the Filters button as "Filters" but rename the item in the ⋮ menu to "Type Filters", but I think that might be more confusing than doing nothing. Overall I think the goal should be to try to communicate a difference between client-side and server-side filters. Maybe "Tusky filters" and "Server filters"?)

mcclure commented 2 months ago

Claire in the other thread informally endorses checking for /api/v1/notifications/policy to test for this feature.

connyduck commented 2 months ago

I got the first part working

It is kinda weird with pull to refresh though. The way I have it now the second item (the first actual notification) will stay in place and the filtered notification count will be pushed up by new notifications. Another possibility would be to always have the filtered notification count visible and push older notifications down. Both feel a bit weird, maybe it is because it is unfamiliar. Thoughts?

cbeyls commented 2 months ago

It feels more like "Filtered notifications" should be sticky on top of the list and not part of it. For example it could use a CollapsingToolbarLayout scroll flag like enterAlways.

connyduck commented 2 months ago

I can do it like that and make it collapse on scroll, but then the top toolbar no longer collapses >_>

What about this? Lacks an explanation what it means, but is easiest to implement and doesn't mess with any scrolling

mcclure commented 2 months ago

Three thoughts:

The bubble is a clever solution but I don't like it because it moves elements and so could mess up my muscle memory for the filter button (which I use a lot). With navigational elements (like the filter change basically is) I like to be able to navigate the UI "without looking" just based on item positions.
Something I really dislike in the Mastodon Web implementation (and have filed bugs on) is that there is no way to tell Mastodon Web "I don't care" about the filtered notifications. There's no UI in the web version to dismiss filtered notifications without looking at them. There's no option to decline to be shown the filtered notification. This is very very weird to me because ostensibly the point of the notification filter is it's content you don't want to see. So the filtered notifications are probably something like spam (which is annoying) or abuse (which can be stressful just to be reminded it is happening). But even though by definition you care less about these things than regular notifications, pulling them out into their own bubble/list actually calls more attention to them than a regular notification, especially if the indicator goes at the top like in Mastodon Web. (The two points I complained about in my Mastodon Web bug are: You have to scroll past the "filtered notifications" list to get to your regular notifications; and you can't dismiss a filtered notification without looking at it. Imagine if you were being harassed, and many people were sending you nasty messages from burner accounts. Now every time you go to your notifications tab you see that filtered-notifications number just counting up and up, and you can't make it go away without going to the filtered notifications tab where you will read all that abuse. I think Mastodon Web shows only who the filtered notifications are from not what is in them, but you still have to see that person's name/avatar.)
What about the bottom? That would be "deemphasized" vs going at the top, and would avert problems with pulldown to refresh. It might be weird with the compose button, but maybe the compose button could move upward. (I realize this contradicts what I was saying about muscle memory, but I'm not sure people activate compose directly from the notifications tab that often…)

This is a long comment sorry. But, I think here are my three possible suggestions for how to handle this. Do one of:

Don't put filtered notifications in the notifications tab at all. (They're filtered, after all). Put it in the left-side bar next to "Follow requests".
Do the filtered notifications notify as a popup at the bottom, which moves the compose button upward, and have it say something like "23 filtered notifications. [Show] [Hide]". That won't interfere with the top tabs, and the user will have the option to dismiss if they don't care.
Include the filtered notifications popup (at the top or the bottom, whichever) but also put in the preferences a checkbox option for "never show me filtered notifications". If the user has selected this and later really needs to see the filtered notifications, they could (whichever) select the filtered notifications pane from the left-side bar (if we do it that way) or we could put a link to the filtered notifications in the ⋮ menu of the notifications tab (if we don't).

In short I don't really agree with Mastodon GmbH that the filtered notifications should be shown to the user at all… and if they are shown in my opinion they should be as de-emphasized as possible, interrupt the user as possible, and be as easy to dismiss as possible.

charlag commented 2 months ago

I just want to add that we probably need to change the whole layout in the app so I would try and not overthink this too much. I really think the two big buttons as they are now is not a good solution and should go but also the bubble has a bit too much emphasis for "things I care less about"

tuskyapp / Tusky