Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formally define a mechanism to remove a follower #471

Open
trwnh opened this issue Sep 27, 2024 · 5 comments
Open

Formally define a mechanism to remove a follower #471

trwnh opened this issue Sep 27, 2024 · 5 comments
Labels
Needs Primer Page Needs a page in the ActivityPub primer Next version Normative change, requires new version of spec

Comments

@trwnh
Copy link

trwnh commented Sep 27, 2024

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. mastodon/mastodon#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.) mastodon/mastodon#5708 and mastodon/mastodon#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?" mastodon/mastodon#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
Copy link
Collaborator

nightpool commented Sep 28, 2024

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
Copy link
Author

trwnh commented Sep 28, 2024

@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
Copy link
Collaborator

nightpool commented Sep 28, 2024

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
Copy link
Author

trwnh commented Sep 28, 2024

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
Copy link
Collaborator

evanp commented Oct 4, 2024

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.

@evanp evanp added Needs Primer Page Needs a page in the ActivityPub primer Next version Normative change, requires new version of spec labels Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Primer Page Needs a page in the ActivityPub primer Next version Normative change, requires new version of spec
Projects
None yet
Development

No branches or pull requests

3 participants