What does it mean that “an ActivityPub service will expose a set of Actors”? Assuming a 1:many relationship between services and actors doesn’t really make sense with the way the C2S spec is written, which assumes that many services may interface with the same actor.
The book series would be semantically represented as an OrderedCollection, rather than a Group.
See Delivering to Collections can be ambiguous · Issue #486 · w3c/activitypub · GitHub on the feasibility of using OrderedCollection as an actor type—tl;dr is that delivery to OrderedCollections is special-cased by the spec (to support collections of actors e.g. the followers collection) and therefore it isn’t possible to deliver to the Collection itself. Instead, I don’t think representing a book series as an OrderedCollection is the best way to go about it (especially since a book series isn’t a collection of Activities!)
The fact that both of your motivating examples in the Motivation section are not possible even if this FEP is adopted does not provide a lot of confidence that this FEP is based on implementation experience for generic platforms. Which platforms are implementing this FEP already? Does Manyfold allow you to follow any actor type? I see in the documentation that it’s currently using a separate property, f3di:concreteType to determine how to deserialize an actor:
(And note that this is just a single controller, so likely similar case statements are cargo-culted into other controllers handling Actor URLs as well). So currently not even Manyfold’s code would allow any type of actor to be handled. How does Manyfold propose that other services allow any type of actor to be handled if they can’t even do it themselves? Practically, how are implementors meant to determine which ActivityPub documents are actors and which ones are not? Just by using the inbox property?
Instead, I think it would be a much more reasonable proposal to handle Actor type extensions in the same way we handle Object extensions, by multi-typing them as explained by ActivtyStreams Core and demonstrated in Example 8:
When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type. For instance, some vocabularies (e.g. The Good Relations Vocabulary) define their own types for describing locations. An implementation that wishes, for example, to use a http://purl.org/goodrelations/v1#Location as an object type MUST also identify the object as being a Place as illustrated in the following:
Example 8
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"gr": "http://purl.org/goodrelations/v1#"
}
],
"type": ["Place", "gr:Location"],
"name": "Sally's Restaurant",
"longitude": 12.34,
"latitude": 56.78,
"gr:category": "restaurants/french_restaurants"
}
An example of this for Manyfold would be the following:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{"f3di": "http://purl.org/f3di/ns#"}
],
"type": ["Person", "f3di:Creator"],
"name": "Stanford University Computer Graphics Laboratory",
....
}
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{"f3di": "http://purl.org/f3di/ns#"}
],
"type": ["Person", "f3di:3DModel"],
"name": "Stanford Bunny",
....
}
(I tried to give this example with a real Manyfold actor document, but I got the error “You need to sign in or sign up before continuing.” when trying to request one from try.manyfold.app. As you can imagine, this is pretty hostile to developers trying to test interoperability. However, I do note in the source code that the CreatorSerializor uses the un-namespaced “Creator” URI, which does not seem to be defined in the @context document)
However, this proposal still requires the unnecessary duplication of core Actor types (what is the difference between a Person and a Creator?)—the amount of extension types should be minimal so as to only cover the use-cases not already covered by the Activity Vocabulary. What is the goal of having two different “user” types?
Finally, a meta note: overall, the FEP process is not a good way to achieve a consensus based decision-making process, because it operates on the principle of “publish everything”, with no editorial or consensus oversight.
The only thing an FEP can say is “This is how my project does X”. Since there is no opportunity for other implementors to weigh in and no editors to achieve harmony between implementation, you often end up with a large plurality of conflicting FEPs that each claim to achieve the same thing in different ways. So it’s inappropriate for this FEP to claim itself as a statement “that all platforms can agree to”, since the FEP process is not designed to resolve conflicts or gather requirements from a wide cross-section of implementors. So even if I thought this FEP was a good idea, I would still object to it on process grounds, because it tries to use the FEP process as a means of forcing the Mastodon project to do something, which is a fundamental misunderstanding of how FEPs work.
