Formally define a mechanism to remove a follower

[trwnh]

Currently, the spec allows you to send a follow request, and when it is accepted, you are added to the followers collection. But there is no consistent way to notify someone that they have been removed from a given followers collection.

Mastodon initially used Undo Accept Follow for this, but this is ambiguous; it is unclear whether the resulting state is to revert to a follow request for which you can send a new Accept Follow, or if it completely destroys the relationship such that they need to send you a new Follow. https://github.com/mastodon/mastodon/pull/8245

It was later decided to use Reject Follow with the interpretation that Reject Follow should always completely destroy a follow relationship, not just a follow request. So if you receive a Reject Follow at any time, then you should interpret that not only as having your follow request rejected (if one was pending), but your server should also remove you as a follower (if you are currently following the sender of the Reject Follow.) https://github.com/mastodon/mastodon/issues/5708 and https://github.com/mastodon/mastodon/pull/6571

There is also a third semantically correct option, which is to send a Remove where the target is the followers collection. Support for this option has not been implemented AFAIK -- Mastodon neglected to implement it due to "the wording in ActivityPub is confusing: the collection has to be owned by the receiving server? Even in S2S?" https://github.com/mastodon/mastodon/issues/5708 and #407

---

Resolution

Primer page that recommends:

• Producers should be aware of the semantic differences of these three options:
  • Undo Accept Follow might be useful if you intend to revert to a follow request, implying that you could receive a future Accept/Reject?
  • Reject Follow could be used to destroy the follow relationship, not just a follow request
  • Remove targeting the followers collection is a valid option despite confusing S2S language about ownership
• Producers should maybe prefer Reject Follow?
• Consumers should expect and be able to handle all three?

---

Tangent: it would be wise to consider the consequences of the more complex Undo Accept Follow and Undo Reject Follow in how they manipulate following state. the implication is that the following flow is possible:

• Follow(1) (follow request)
• Accept(2) Follow(1) (following)
• Undo(3) Accept(2) Follow(1) (back to follow request)
• Accept(4) Follow(1) (back to following?)

which may be delivered out-of-order as:

• Follow(1) (follow request)
• Accept(2) Follow(1) (following)
• Accept(4) Follow(1) (still following? no-op?)
• Undo(3) Accept(2) Follow(1) (back to follow request?)

likewise but with a Reject:

• Follow(1) (follow request)
• Reject(2) Follow(1) (no relationship)
• Undo(3) Reject(2) Follow(1) (back to follow request?)
• Accept(4) Follow(1) (following?)

which may be delivered out-of-order:

• Follow(1) (follow request)
• Accept(4) Follow(1) (following)
• Reject(2) Follow(1) (destroy the follow? back to no relation?)
• Undo(3) Reject(2) Follow(1) (??? back to following? or no-op?)

so the safest thing seems to be to advise producers to avoid sending these complex activities entirely.

[nightpool]

I feel like "Block / Unblock" is the most idiomatic way to remove a follower on any social media network........ I've never seen a website that didn't support it. Conversely, I can't really think of any popular non-federated websites that support explicitly removing a follower like you propose.

[trwnh]

@nightpool Block/Unblock also destroys your following relationship, so you have to resend a Follow afterward, which might not get accepted

Misskey and Pleroma let you "remove a follower" without block/unblock. i don't think they're the only ones.

[nightpool]

Block/Unblock also destroys your following relationship, so you have to resend a Follow afterward, which might not get accepted

Is this a use-case that anyone has ever had? What's the user story here? Feels like we're just adding complexity for no good reason.

[trwnh]

user story: "as a user, i want to remove someone from my followers collection, without also unfollowing them"

this is a real use-case that i have personally seen be handled disastrously on multiple occasions, and that's only the occasions i'm personally aware of. it is a problem made infinitely worse by the existence of sharedInbox and the practice of sending activities addressed to followers collections to that endpoint (i.e., non-Public activities being sent to what is only reliably defined as a Public endpoint)

there are simply a lot of problems surrounding the "follow state machine" that implementers have come to depend upon if they want related functionality to work correctly. what happens in the "followers-only post gets delivered to shared inbox" case is that the server will be unaware that a certain follower has been removed, and will ignorantly continue to show that followers-only post to someone that is locally seen as a follower but at the authoritative remote has actually been removed as a follower. there are other mechanisms that can be used to attempt to rectify this (like the FEP for "follower collection synchronization" that mastodon implements) but in general, there ought to be some way in-spec of knowing that you are no longer following someone. this is up to the remote to either remove you silently from the collection (in which case we need a mechanism to stop delivering private followers-only posts to the removed follower, or alternatively and much more likely, we need a mechanism for multi-inbox delivery that isn't sharedInbox), or it's up to the remote to remove you explicitly by sending some kind of activity indicating that you have been removed (in which case you know explicitly to destroy that follow relationship)

[evanp]

I think the two next steps for this process would be first documenting the different options that are actually used on the Fediverse today, as well as the suggested collection-management, on the Primer.

A second step would be picking a preferred method and adding it to the next version of ActivityPub.