for those unaware: if you send an unfollow and refollow too closely to each other, the unfollow might fail due to desync issues, then get retried after the follow is successfully processed... which destroys the *new* follow.
9
Replies
0
Boosts
from my experience, akkoma makes 5 attempts, with retry intervals of about 15 minutes, so you should wait at least 1 hour and possibly a bit more depending on processing time for other activities (in case the server is under any amount of load and isn't processing activities ~instantly).
servers making use of exponential backoff strategies might take even longer, although i haven't personally observed any.
here's a snapshot of the results of what people thought before this post was made.
i'm not aware of any fedi software that warns about this, and arguably there are things that can mitigate this -- say for example fedi servers were required to store and compare specific ids of Follow activities, so that you can Undo them unambiguously. that does create an issue of what to do if you no longer have the follow id anymore... maybe a safety valve property that signals "undo any existing follow before this timestamp". but this requires agreement and updates to existing servers...
on multiple occasions, i've had people unable to follow me because they sent a Follow that got dropped, then tried to unfollow-and-refollow after whatever issue got fixed. i'm not sure at what point we get to say "hey, maybe the fedi Follow State Machine model is broken". this isn't the only issue with follows desyncing. desyncs happen more than most people realize. maybe that person you're "following" hasn't been sending you their posts. maybe you've got "followers" who aren't seeing yours.
i'm not sure what to do to fix this issue across fedi. one way would be for everyone to agree to track followers at the sending side only, no need to sync follower lists. another way would be for everyone to agree on a stricter algorithm for how the state machine should work with stronger consistency guarantees (and a way to verify state). unfortunately everything requires broad agreement and isn't easily fixable.
@trwnh I think a decent idea would be for servers to only act on follow & unfollow requests at fixed intervals.
So that when you press follow, you tell your server that you intend to follow, but the server just says "I'll put that request in the next bucket". The buckets of requests get sent every 15 mins (say), and if you click unfollow and refollow and unfollow or whatever before that bucket of requests is sent, then it just updates what it is the bucket; which is easy because its local.
Downside would be that you might miss a post of someone you just followed if they sent the post before your bucket went out.
@karadoc Maybe, but the fundamental root of the issue is that servers need to coordinate perfectly to sync follower state in the first place.
So for an optimal fix, you need to allow for fetching the latest state on the tracking server, and/or you need to put the question entirely into the hands of the tracking server.
The fact you can't verify whether a follow relationship still exists is a major flaw of the current model.
