ok it took me 2h apparently :D
Notices by ThibG[uimauve] (thib@social.sitedethib.com)
-
ThibG[uimauve] (thib@social.sitedethib.com)'s status on Thursday, 12-Sep-2019 22:34:59 UTC ThibG[uimauve] -
ThibG[uimauve] (thib@social.sitedethib.com)'s status on Tuesday, 13-Aug-2019 09:01:30 UTC ThibG[uimauve] 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 allEvery 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.
-
ThibG[uimauve] (thib@social.sitedethib.com)'s status on Tuesday, 16-Apr-2019 16:24:50 UTC ThibG[uimauve] @cwebber yes :blob_cockatiel: