tech, Mastodon, fediverse blocks, long 

Mastodon currently features two ways, as a user, to limit interactions with a given user, and one way to limit interactions with a given instance.

Regarding users, they are mute and blocks.

Muting an user means you don't receive notifications from them and you don't see them in your timelines. It doesn't give that user (or their instance) any information or require any collaboration from their instance.

Blocking goes a bit further by doing a few things:
1. Forcibly remove them from your followers and auto-reject follow requests (whether or not your account is locked)
2. Hide *your* content from them
3. (it's a bit of a side effect to 2) prevent them from interacting with you at all

Every single of those things can give out to that user that you're blocking them, though, and if they are remote, every single of those requires some kind of cooperation from their end:
1. If you have non-blocked followers on their instance, you're still sending your toots (including private) to that instance, so if the instance doesn't respect the “forcibly remove them from your followers” part, you're fucked. Ultimately, there is no way around it, but the protocol design could have been less error-prone.
2. This is mildly useful, can be very easily bypassed (just opening the profile in a browser for instance), and requires full collaboration from the instance their are on. Ultimately we can't do much better with regards to that particular limitation.
3. I'd argue this is more useful than 2. as preventing people from boosting and replying from blocked actors reduces the amount of exposure your content is likely to get in those circles you want to avoid. However, no matter how you look at it, this requires collaboration as well. But it should be possible (although very involved) to not require the collaboration of the very instance that is hosting offending actors (basically, you'd ask the instance of the blocked user if they accept the interaction and ask them to give proof that they do, then attach it to the interaction, and every collaborating instance would only accept it if it comes with proof)

Now, instance blocks. They're a mess. They are called “Hide instance” and it's not obvious if they block or mute instances. What they actually do, as far as I can tell, is:
1. Forcibly remove followers from that instance (thus requiring collaboration as stated previously, even if that's less of an issue because of 2.), reject any pending follow request from that instance
2. Stop sending anything from your account directly to that instance
3. Avoid showing you content or notifications from that instance
4. [in the development version only] if the “authorized fetch mode” is enabled, do not allow that instance to fetch anything (even public statuses)

The first and last point possibly give away (the first one proactively if you have any follower from that instance, and the last one passively) that you are blocking that instance, although it's not as obvious as the `Block` activity from user blocks.

tech, Mastodon, fediverse blocks, long 

@Thib Isn't there also instance level "silencing" - "A Mastodon silence is synonymous with sandbox. A silenced account does not appear to users who are not already following it. All of the content is still there, and it can still be found via search, mentioned, and followed, but the content is invisible.

At this moment, silence does not affect federation."

Or am i confusing that? (Possible).


re: tech, Mastodon, fediverse blocks, long 

@Tchambers I was listing actions users can take part in, without being admins

Admins have a few more options, which are very roughly equivalent to user ones but at the instance levels (there are differences but I don't want to get into it at the moment)

re: tech, Mastodon, fediverse blocks, long 

@Thib All good; very cool and helpful thread. Thanks.

Sign in to participate in the conversation
Mastodon (instance perso)

This is a small personal instance running on a couple small ARM servers at home.