how blocks work on mastodon

This morning I was reading someone explain why “soft-blocks” (blocking someone to stop them from following you, then unblocking them so it's hard for them to see what you did) don't work right now on #Bluesky, because a “block” and a “follow” are both things that are owned by individuals. I can block you, and I own (and publicly declare) that block, but I can't impact your “follow”. You own that, and I can't touch it.

So that was all very interesting but it made me realize I don't actually know how blocks work in a Masto-alike (or #ActivityPub generally) network, so I started bopping around looking stuff up. Almost immediately, I found this Understanding ActivityPub series from @crepels@mastodon.social. It's a great series, but the test instance is spectacular. Here's how blocks and follows interact between two #Mastodon instances:

1. I follow my test user by sending a Follow to the test user's inbox, and the test user sends my inbox an Accept:
2. When the test user blocks me, a few things happen:
   • The test user sends my inbox a Reject for the Follow it previously accepted.
   • The test user sends my inbox a Block. (This one's interesting; we'll get to that in a minute.)
   • I send the test user's inbox an Undo for my initial Follow

Mastodon handles blocks and follows by automatically unfollowing the blocking user from the blocked user, and that's why soft-blocks work. I can't declare a Follow unless the person I'm following consents, and the person I'm following can withdraw that consent at any time.

but wait the spec says

The ActivityPub specification doesn't say much about blocking, but it does say

Servers SHOULD NOT deliver Block Activities to their object.

Making blocks public is fraught, so the ActivityPub recommendation makes sense. Clearly Mastodon is sending the Block activity to the object, so why is it ignoring the spec? Here's the official docs:

Mastodon will send this activity when a local user blocks a remote user. When Mastodon receives a Block activity where the object is an actor on the local domain, it will interpret this as a signal to hide the actor’s profile and posts from the local user, as well as disallowing mentions of that actor by that local user.

Essentially, Mastodon servers on both ends of the Block activity need to hide content that should be blocked from their users' feeds. The test user's content might still end up on my server, so my server needs to know that I should never see it.

all of this is hard and none of this is static

There are a bunch of people contemplating soft-blocks in Bluesky (and they've got a writeup with a summary of options), and a bunch of people contemplating block federation in Mastodon. Consent and safety are hard problems in a decentralized^* network because they interact with ownership and agency, and I'm kind of glad there are different communities with different approaches working towards solutions.

^* Yeah yeah I know, Bluesky's not decentralized, but it really wants to be and the people building it care about that, so it counts here.

from @ello@void.ello.tech