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 

To be honest, I think each of those blocking mechanisms has its merits, and it's not possible to get them to be much better than that.

I believe there are things that could be improved, though:
1. Make it more obvious what each of those mechanisms do. For instance, that blocks require cooperation from the remote instance and give them the information is not made clear to the user. It should be.
2. We should have something like “mute + prevents follow even if your account is not locked”, not rejecting the follow, but not sending accepts
3. Have actual domain mutes, and make clear what domain blocks actually are.
4. Prevent unwanted interactions with things like domain capabilities and collaborative enforcement. This would be a modest improvement in that you would still require collaboration, but not from the people/instances you've explicitly identified as bad. This one is a lot of work on both the protocol level and the implementation level, though, so it's not going to be there anytime soon.

Show thread

re: tech, Mastodon, fediverse blocks 

@Thib how much of that would be "solved" with OCAP?

Follow

re: tech, Mastodon, fediverse blocks 

@hirojin just 4. basically. Object capabilities aren't going to help you much with people seeing your public toots or instances not respecting the privacy settings of toots they already have a hold on. Nothing will.

re: tech, Mastodon, fediverse blocks 

@Thib i thought with OCAP you could introduced "authorized fetch"?

re: tech, Mastodon, fediverse blocks 

@hirojin we have authorized fetches (in the development version), they don't really have anything to do with object capabilities

what they can do is prevent an explicitly-blocked instance from getting a hold on your toots, at some cost

and they are somewhat easily bypassed

things are different in a whitelist-based federation setting, though, where they are more useful (as they can very effectively prevent anyone not part of the whitelist from getting a hold on your toots), and in which the current Block model is more viable (because you a priori trust the instances you federate with not to ignore the blocks or notify users of them)

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.