Hard muting

[yiskah]

Text from corresponding issue on tootsuite:

"The primary function of muting for me, as a high follower-count user, is to remove someone's comments from my notifications without them knowing I have done so (via not seeing my posts etc). Block = "I don't want this person to see me", Mute = "I don't want to see this person." If I block a troll they claim it as a victory and I just get more trolls. If I block someone who is an "overzealous fan" I've had quite a few incidents of them tracking down my contact info (via my website, the mastodon discord server, etc.) and interrogating me on what they did wrong, when I never wanted to bother with that conversation and wished I could use mute to avoid that social drama. I also sometimes get others hearing I blocked someone and asking what they "did wrong" when it was really just that they replied to my posts too much with inane comments.

Expected behavior: A muted user's mentions or replies of me do not show up in my notifications, as on other social media. Actual behavior (v1.4.1): A muter user's replies and mentions of me show up in my notifications.

Muting is essentially useless to me when it has such a large hole for harassment to go through. Blocking people who harass me always makes them go brag about it and then others seek to get blocked as well. I haven't muted any servers but if muting a server behaves like muting an individual user then that also removes that feature's anti-harassment aspect."

On glitchsoc we could have a "soft mute" and "hard mute" for the two behaviors

---

• [X] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [ ] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[ekiru]

I think domain silences do work as a hard mute fwiw. but we should def add this for users too (as a distinct option in addition to the current soft mute since some people really like the soft mute).

If no one else wants to grab this I plan to look around the code for muting/blocking to plan out how best to implement the functionality side of this tonight (in UTC-5).

One question I do have is how we want to call the two different "mutes". Probably one can stay mute and the other can be... something. I'm not sure what would be good.

[yiskah]

Well, maybe I'm just in love with modals but it'd be most semantically transparent if like, when you mute someone there's a modal that has a checkbox which says "[X] Also hide from notifications?"

This doesn't streamline things as much but also the ... menu has been getting really long and it'd i think be better to not create like

Block @user
Mute @user
Hide @user from Timelines
Report @user

it gets a little intense

[ekiru]

I like that idea a lot for the UI for it.

[ekiru]

So I think on the server side the necessary changes are:

• [ ] A migration to add a boolean column named "hard" or "hide_notifications" or something to the Mute model.
• [ ] A method added to app/models/concerns/account_interactions.rb called muting_notifications? or something like that which checks that there exists a Mute for the muting user's account and targeting the muted user's account with the new column set to true.
• [ ] Modifying the blocked? method in app/services/notify_service.rb to return true when the recipient hard mutes the from_account of the notification. (I think this is as simple as adding a blocked = @recipient.muting_notifications?(@notification.from_account) somewhere in there).
• [ ] Either modify the GET /api/v1/mutes API endpoint to return information about whether the muted accounts are hard muted (perhaps in a parallel array or dictionary of mute options to the array of Accounts) or add a separate GET /api/v1/hard_mutes or similar (or a parameter to the former) to return specifically hard mutes.
• [ ] Add a (probably query) parameter to the POST /api/v1/accounts/:id/mute endpoint to specify hard muting.
• [ ] Expose muting_notifications in the Relationship for a targeted user.

On the web client side the following things would need to be done:

• [ ] In the "are you sure you want to mute this user" modal, add a checkbox (defaulting to ???) saying something like "Also hide from notifications" like @yiskah suggested.
• [ ] When sending the POST /api/v1/accounts/:id/mute request to mute a user, send the ?hard=true query parameter or whatever if the checkbox was checked.
• [ ] When displaying a user's mute list (or a user as muted), indicate that it's a hard mute somehow.

Open questions:

1. How to indicate which user's are hard muted versus soft muted when displaying mute list?
2. Do we call it in the API and stuff hard muting or muting_notifications or what?
3. Do we want to add any other further effects of hard muting (e.g. I think @hoodiek wants mutes to mute other people's mentions of the muted person, which perhaps could naturally fit in a hard mute)? Do we want to add those as distinct options when muting instead? This one doesn't really need to be figured out before implementing the notification muting though it could make API naming choices a little better or worse.

I'll probably start working on the server side of this tonight (assuming no one's bothered by my plan) though it may be later this weekend by the time it gets done.

[yiskah]

You're fantastic

[ekiru]

After talking with @beatrix-bitrot I'm going to break this up into a few separate phases of implementation. After phase 2, people will be able to hard mute people and it will hide the appropriate notifications, but there won't be any easily checkable indication of whether you hard or soft muted someone. The work necessary for that bit will be completed in phase 3. I'll probably get started on phase 1 at least this weekend. :)

Below are those checklist items above separated out into phases:

Phase 1: Backend functionality support

At the end of this phase, the server will be able to store hard mutes and will correctly block notifications from hard muted users, but there won't be any interface by which to actually hard mute someone.

• [ ] A migration to add a boolean column named "hard" or "hide_notifications" or something to the Mute model.
• [ ] A method added to app/models/concerns/account_interactions.rb called muting_notifications? or something like that which checks that there exists a Mute for the muting user's account and targeting the muted user's account with the new column set to true.
• [ ] Modifying the blocked? method in app/services/notify_service.rb to return true when the recipient hard mutes the from_account of the notification. (I think this is as simple as adding a blocked = @recipient.muting_notifications?(@notification.from_account) somewhere in there).

Phase 2: Basic UI and API support

At the end of this phase, users will be asked whether they want to hide notifications from the muted user when muting but won't have a way to tell whether they opted to do so when going back and looking at their mutes.

• [ ] Add a (probably query) parameter to the POST /api/v1/accounts/:id/mute endpoint to specify hard muting.
• [ ] In the "are you sure you want to mute this user" modal, add a checkbox (defaulting to ???) saying something like "Also hide from notifications" like @yiskah suggested.
• [ ] When sending the POST /api/v1/accounts/:id/mute request to mute a user, send the ?hard=true query parameter or whatever if the checkbox was checked.

Phase 3: UI/API support for viewing your hard mutes

At the end of this phase, users will be able to see easily whether they're soft or hard muting someone else and the feature will be thoroughly complete I think. :)

• [ ] Either modify the GET /api/v1/mutes API endpoint to return information about whether the muted accounts are hard muted (perhaps in a parallel array or dictionary of mute options to the array of Accounts) or add a separate GET /api/v1/hard_mutes or similar (or a parameter to the former) to return specifically hard mutes.
• [ ] Expose muting_notifications in the Relationship for a targeted user.
• [ ] When displaying a user's mute list (or a user as muted), indicate that it's a hard mute somehow

[ekiru]

Just commenting to note that in upstream all mutes got change to hard. So I'm going to implement soft mutes instead as an option when muting someone hehe. (well, probably I'll just do the same implementation as I would have done before and remove the upstream change but).

[hannahwhy]

It seems like both the soft and hard mute behaviors now exist in glitchsoc. Can this issue be closed?

[beatrix-bitrot]

yep i think we're all good here, closing!