Does anyone know if there are guidelines for the Follow/Accept flow outside of that prescribed in the AP protocol?

The reason why I ask is because there seems to be a little logical hole that people fall into where a Follow activity is sent, but the relationship then rests in an indeterminate state:

1. The Follow is pending acceptance
2. The Follow was already seen and subsequently ignored
3. Something was wrong with the activity (e.g. signature failure, missing id, etc.) and it was ignored

Receipt of an Accept is asynchronous, so the approach as seen in the wild is to assume a "pending" follow state. The problem is that if the flow doesn't follow that happy path (instant-accept or pending), then you don't know there is a problem.

Furthermore it seems that there are no existing recommendations regarding handling of a Follow to an Actor who believes you are already following them. Do you send back an Accept? Ignore the activity?

I'm writing this because I'm unable to follow @weekinfediverse@mitra.social, but I don't actually know whether it failed or is pending accept.

While I firmly believe any errors would be on my end, the problem is I don't actually know for sure, and this would also potentially provide guidance for new implementors.

cc @silverpill@mitra.social

@julian I just followed that account on Mastodon and it immediately followed. I don’t think they have it set to have to manually accept new followers, so I think your follow failed.

@julian

>The problem is that if the flow doesn't follow that happy path (instant-accept or pending), then you don't know there is a problem.

In such cases I keep it in pending state forever. But the sender may cancel and re-send the follow request.

>Furthermore it seems that there are no existing recommendations regarding handling of a Follow to an Actor who believes you are already following them. Do you send back an Accept? Ignore the activity?

I send Accept every time, i.e. Follow activity is idempotent

>I'm writing this because I'm unable to follow `@weekinfediverse@mitra.social, but I don't actually know whether it failed or is pending accept.

It was successful, and my server sent Accept, and the response was:

[202]
{"status":{"code":"accepted","message":"Accepted"},"response":{}}

>...the problem is I don't actually know for sure, and this would also potentially provide guidance for new implementors.

There was a discussion about error reports: https://socialhub.activitypub.rocks/t/report-errors-in-server-processing/3006
But none of the proposals were implemented

Receipt of an Accept is asynchronous, so the approach as seen in the wild is to assume a "pending" follow state. The problem is that if the flow doesn't follow that happy path (instant-accept or pending), then you don't know there is a problem.

Furthermore it seems that there are no existing recommendations regarding handling of a Follow to an Actor who believes you are already following them. Do you send back an Accept? Ignore the activity?

https://wiki.trwnh.com/tech/spec/activitypub/follow/

In short: sending an Accept (or Reject) is, or ought to be, a courtesy to let someone know that their Follow request was successful. In a pure subscription / peer-to-peer delivery situation, this would be the case. However, there is one big issue with this -- the existence of sharedInbox. Delivery to the followers collection specifically via sharedInbox means that the receiving server MUST be aware of who is included in that followers collection. This turns the Accept from a mere courtesy signal into an important state-synchronization message. And consequently, state may become desynced for any of a large variety of reasons. So if you get a Follow from someone who is already following you, it probably means that their state got desynced, and you should send an Accept Follow to "remind" them.

There's a tangential point about "missing id" or even "unexpected id": namely, the ID of the Follow activity often doesn't matter, as the "shape" of the activity is more important in actually processing it. Some implementations pass around partial reconstructions of this activity by its shape.

I'm not sure if this rises to the level of needing a FEP, but I can see a FEP being needed for more advanced follower collection manipulation like removing a follower, which, again, ought to be something you can just do and otherwise send a courtesy notice that you did so... but because of sharedInbox, it suddenly becomes critically important to understand such messages. See also: https://github.com/misskey-dev/misskey/issues/11015 and https://github.com/w3c/activitypub/issues/384 as it pertains to id-less Follow activities within Accept or Reject.

Of course you have a wiki page for this already! Why am I not surprised.

Yes, that follow-accept has state synchronization responsibilities means that some additional specification would be nice, though as long as everybody tends to conform to the same behaviour I suppose thats less urgent.

I still don't like that the current UX is "follow is in a pending state", but short of additional specification re: error handling, there's not much to do here.

At any rate it seems I am now correctly following @weekinfediverse@mitra.social so I suppose maybe my server was slow at processing the accept.