-
Notifications
You must be signed in to change notification settings - Fork 78
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
Comments
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. |
@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. |
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. |
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 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) |
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. |
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 givenfollowers
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 newAccept Follow
, or if it completely destroys the relationship such that they need to send you a newFollow
. mastodon/mastodon#8245It was later decided to use
Reject Follow
with the interpretation thatReject Follow
should always completely destroy a follow relationship, not just a follow request. So if you receive aReject 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 theReject Follow
.) mastodon/mastodon#5708 and mastodon/mastodon#6571There is also a third semantically correct option, which is to send a
Remove
where thetarget
is thefollowers
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 #407Resolution
Primer page that recommends:
Undo Accept Follow
might be useful if you intend to revert to a follow request, implying that you could receive a futureAccept
/Reject
?Reject Follow
could be used to destroy the follow relationship, not just a follow requestRemove
targeting thefollowers
collection is a valid option despite confusing S2S language about ownershipTangent: it would be wise to consider the consequences of the more complex
Undo Accept Follow
andUndo 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.
The text was updated successfully, but these errors were encountered: