Federated mutual Blocks can lead to irreconcilable state desyncs

[trwnh]

Background

From https://www.w3.org/TR/activitypub/#block-activity-outbox we see that:

The server SHOULD prevent the blocked user from interacting with any object posted by the actor.

Servers SHOULD NOT deliver Block Activities to their object.

Core assumption: an active block results in incoming activities being dropped, perhaps with a 403 Forbidden or perhaps not.

Steps to replicate:

• A Block B.
  • State A:
    • A blocks B
    • B does not block A
  • State B:
    • A blocks B (a Block was received)
    • B does not block A
• B Block A.
  • State A:
    • A blocks B
    • B does not block A (because B Block A was dropped)
  • State B:
    • A blocks B
    • B blocks A
• A Undo Block B.
  • State A:
    • A does not block B
    • B does not block A (because B Block A was dropped)
  • State B:
    • A blocks B (because A Undo Block B was dropped)
    • B blocks A

Resolution

Primer page on Block activities: https://www.w3.org/wiki/ActivityPub/Primer/Block_activity should note that Block activities should not be federated, but should also note that Block activities are often federated despite this guidance.

In the case that Block activities are to be federated, they should probably be sent to a moderation actor or moderation inbox, rather than being sent directly to the blocked actor. See swicg/activitypub-trust-and-safety#24 for more on this.

More generally, guidance could be given on mechanisms for how an active block should "prevent the blocked user from interacting". We assume above that dropping the activity and possibly returning a 403 Forbidden is the chosen approach, but there may be other interpretations of "prevent [...] from interacting".

At least in the case where Block activities aren't federated but result in a 403 response, we have the following flow instead:

• A Block B.
• B Block A. This may return 403 if delivered directly to A.

The difference here is that if A Undo Block B, then B would be able to notify A that they have been unblocked. Essentially, the block is "dynamic" in that you never actually notify the other party, but they might be able to figure it out, but undoing the block also doesn't represent a state machine change, it only represents a change in policy. If the state machine is to be changed, i.e. if a follow relation is to be severed, then see #471 for that.

[nightpool]

Core assumption: an active block results in incoming activities being dropped, perhaps with a 403 Forbidden or perhaps not.

This assumption makes no sense to me. I don't think we need a spec issue to describe why this assumption is mistaken. Why would Block activities prevent processing of all incoming activities? Surely some activities, like Delete or Block, still make sense to process. The spec does not imply that all incoming activities are blocked, just that "The server SHOULD prevent the blocked user from interacting with any object posted by the actor". A block activity is not really "interacting with the actor" in any substantial way.

[trwnh]

This assumption makes no sense to me [...] Surely some activities, like Delete or Block, still make sense to process [...] A block activity is not really "interacting with the actor" in any substantial way.

POSTing to my inbox is an interaction.

Those activities should be sent somewhere else other than to the inbox of a user who blocks you. For example, to an actor or inbox representing the Service itself or its moderators rather than directly to a user who is blocking you.

[evanp]

I agree that although this is a SHOULD NOT process, it MAY still happen, and it's worth documenting what the process would be. I think that a primer page on the Block activity would be warranted, and probably could include some information both about why Blocks SHOULD NOT be federated, and what to do when they are. I don't think that we expect very consistent or usable interactions if implementers ignore the SHOULD NOT guideline, though.