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

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

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?

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.