Mastodon: muting and blocking tools to surpass twitter

[hoodieak]

UPDATE/progress: User Blocking works as it should/can RE federation and the like.

Things that need to be implemented still:

423 covers the domain part of blocking that remains needing implementation

Muting of users still needs to be implemented, preferably with an option to allow them to mention you and be visible to you in your mentions alone
Muting of keywords remains needing implementation

ORIGINAL POST IS AS FOLLOWS:

first: blocking should become muting as it is in its current form. this includes people who have already muted people. this is because in it's current iteration: that is what it is, a "hard mute"
(EDIT: by this word jumble i mean that current blocks should automatically become hard mutes when this update hits.)

i propose another form of muting, and also the actual blocking that is necessary.

a block should add a hard mute as well.

A hard mute will keep ALL POSTS from said user from making it to any feed. mentions to you, mentions to them, replying to you, etc. this will NOT let the user know they are muted in any way

a SOFT MUTE is what should happen if you just don't like someones original content: replies to you will still show up. this is to help people with large accounts manage it, and i believe it just as necessary as a hard mute function.

BLOCKING should do all that HARD MUTE does. namely, removing all posts from said users timeline and such.
it should also make it so that IF THEY ARE LOGGED IN: the person who is blocked cannot view, reply to, or interact with any posts from someone who has blocked them. this is good because it allows the person who has done something noticeably wrong to KNOW they have, and also makes it impossible for them personally to harass the one who has blocked them

i would also suggest "instance mute" for muting an instance personally from all posts.

finally: a separate mute function for keyword muting. all of these should have a menu to manage them, ideally, as well, to let people change their mind without having to remember the people.

in regards to more fancy blocks, the main thing i personally would like is person-specific-text blocks. IE: from user A, mute "#nsfw" etc

instance based mutes are also something that users like myself would appreciate

thanks for listening, keep up the great work.

[triplefox]

Summarizing this into a list

• Soft Mute: Target's direct replies to you are seen, nothing else
• Hard Mute: Target is not seen from any of your views
• Block: Target cannot see you either
• Keyword Mute: Filters by keywords independent of account muting
• Instance Mute: Filters an entire other instance from the network

I think this is a pretty good proposal!

[hoodieak]

https://t.co/Lzlv1ycPJb i was also pointed toward this, a more advanced set of tools used for twitter and the like. currently just asked them if they'd be willing to contribute these advanced regex-style muting tools to Mastodon

[triplefox]

Oh, also, it's become obvious that these other federated instances don't care for Mastodon so we should probably have a filter by instance?

[hoodieak]

gonna edit that into main post, also maybe your summary could use it too. "mute instance" is a very very good plan

[hoodieak]

more: https://twitter.com/EylerWerve/status/801472342660620288 @Gargron maybe worth contacting this user, he is willing to contribute more advanced tools as well, including research based lists of abusive words and regex muting

[hoodieak]

asking for opinions elsewhere, i got this: "One thing I'd suggest is that blocking someone should make it so that any of their replies to your posts should no longer be considered threaded, even for other people viewing your post (assuming Mastodon has that feature)" i figure this is probably possible

[marrus-sh]

I agree with the namechange to "mute" as I feel it prevents confusion, but actual blocking isn't possible because of Mdon's federated nature—there's no way of ensuring that a given instance will respect a block. See the last question on the FAQ. Local blocking could be implemented (say, just within mastodon.social), but this would only drive harassers to make their own block-free instances (and drive all other users onto a single instance).

It might be possible—I am not clear on the specifics of this?—to block an entire instance from accessing someone's toots, and if so then it might be possible to block all non–block-respecting instances, through a user-level preference like "Require block support". In this situation, a federated block system would be feasible as respect for the block is already a precondition for toot access. I am still not positive that this could be implemented except through a faith-based system though? Or, perhaps, a faith-based system and a blacklist.

This of course requires some means of federating blocks and I am not well-versed enough on the internals of GNU Social to know if that is possible.

[marrus-sh]

[Note that even in this instance ^ a block would not (be guaranteed to) cause an unfollow, it would only prevent the blocked user from seeing the other's tweets (with a possible message?)]

[hoodieak]

thank you so much for explaining that stuff, that was something i was very worried about. hopefully @Gargron drops in here sometime with some thoughts on the matter. when it comes down to it i'm a coder that knows nothing about websites and the necessary stuff for coding this, so i'm mostly trying to help make features that are necessary be organized and set up in github to make gargron's job easier

[triplefox]

Suggestion from DarkestKale: mute toot (to stop a popular one from reappearing infinitely)

[swaldie]

Referencing #194 which is a much more specific issue but related to this conversation.

[daliacoss]

i hope that i am not stepping out of turn when i say that, with the rise of instances like alt-right.space, developing a means to mute other instances should be considered high priority. while hard blocking is apparently a non-trivial problem, creating filters for the existing mute feature seems to be within reach and i think it's much needed right now.

if people's hands are too tied to work on this, i would be willing to chat on IRC with @Gargron or whoever else is familiar with the code base about how i could submit a patch for this myself.

[hoodieak]

i would agree that it's a high priority. hard muting is i believe already in effect? just named "blocking"

i would say the priorities are:
keyword muting
instance muting/blocking on a per user basis
hard muting/name change
soft muting i would personally appreciate but is less necessary.

blocking needs the name changed for sure, and while blocking is rather necessary long term, from general consensus, i believe these tools i referenced are top priority and not too hard to complete. this is not an accurate view of difficulty, however, as i am not a web coder and couldn't say beyond the conversations i've seen around.