FEP-efda is a significant departure from the ActivityPub specification, which only defines Follow and its side-effects for actors:
The Follow activity is used to subscribe to the activities of another actor
Also, followable collections might not be compatible with FEP-fc48: Generic ActivityPub server. If you like the idea of a generic server, I suggest keeping Follow tied to actors (as ActivityPub prescribes), at least until we figure out how collections ought to work.
Do you mean “departure”, as in, extension to ActivityPub? I think that describes a majority of FEPs. It’s definitely consistent with the AS2 description of the purpose of Follow, which is not actor-specific.
However, I’m not saying I think FEP-efda is the best way to do it and I agree that general collection management needs much more definition.
Do you mean “departure”, as in, extension to ActivityPub?
FEP-efda starts with a false claim "ActivityPub does not specify a full algorithm for how to follow something" (ActivityPub does specify the full algorithm). Then it presents an alternative to the behavior described in the specification.
I guess it could have been an extension, but it is not presented as such in the FEP.
Maybe @trwnh should change “something” to “an arbitrary AS2-compatible object type” if it’s causing that much confusion?
That would be a good start.
Where in https://www.w3.org/TR/activitypub does it specify where to send a Follow activity?
The only statements made by the spec right now are:
followers collection. (4.1, 5.3)following collection [and we are again assuming “the receiver” means Follow.actor here] (7.6)There is an omission of any statement whatsoever that POSTing a Follow to an outbox SHOULD address the Follow.object specifically. It is equally possible for the Follow to be addressed to an id other than the Follow.object. It is also equally possible for the Follow to not be addressed to anyone. This means that the normative recommendations in points 3 and 4 above will never be reached. It’s not a “significant departure” to deliver to the Follow.object.attributedTo.inbox instead of the Follow.object.inbox. We already do basically this for every other activity! When you want to send a Like activity, do you deliver to Like.object.inbox or do you check Like.object.attributedTo.inbox? In general, ActivityPub doesn’t prescribe who SHOULD or MUST be addressed for any given activity; it leaves that entirely up to the client to choose who gets addressed (per 6.1 “Client addressing” if using the outbox, and per whatever your bespoke implementation logic if delivering directly to inbox).
The whole point of FEP-efda is to fill in this gap. The algorithm in FEP-efda (unfortunately poorly rendered by Markdown processors) describes how you can check for the presence of followers and inbox, then if inbox is missing, you can instead check for attributedTo.inbox. Either way, it will arrive at an inbox where hopefully points 3 and 4 above can actually be triggered. Or there is no inbox discovered within the recursion limit, and so even though a resource may have a followers collection, it is practically impossible to be added to it via ActivityPub. (It may be possible to get added to it via other mechanisms.)
Where in https://www.w3.org/TR/activitypub does it specify where to send a Follow activity?
I already cited the relevant statement from section 6.5:
The Follow activity is used to subscribe to the activities of another actor
Not sure why you keep denying that this text exists. Anyway, all these points were discussed at length in other threads, and I am not interested in repeating them here.
“The Follow activity is used to subscribe to the activities of another actor” does not say anything about where to send the Follow activity. I am not “denying that this text exists”, I am in fact referencing it (2) and saying it is incomplete.