Currently there is the problem that the same thread on different systems most likely will contain different posts. This lead to tools like FediFetcher that create a high load on systems. So I think that we need some technique to distribute the posts. This can be done with these steps:
The original system should always forward all incoming comments to all participants of that thread (and the original receivers) (of course only when the post is public)
To notify the original system that some other system is interested in posts of a given thread, one could send a Follow request directed to the URI of the first post of the conversation. (the request should be done by the system actor and should be directed to the system actor of the other system)
When the Follow arrives, the target system should forward all currently existing comments to that server.
Concerning the second point I don’t mind which actor is used for that. Concerning the Follow on non actors: Have a look at the spec: Activity Vocabulary
Indicates that the actor is “following” the object. Following is defined in the sense typically used within Social systems in which the actor is interested in any activity performed by or on the object.
In that specific case we are interested in any activity on that conversation. So from my point of view it does make sense.
Having to parse through these collections does habe two major disadvantages:
it puts a higher load onto the systems, since you additionally have to fetch these collections and have to fetch each individual post by yourself.
You would had to regularly parse through all these collections to really get all comments.
Going though the collections for my third point is okay, but for the second one this isn’t a workable solution.
Concerning your mentioned “context collection”: Currently I’m only aware of the replies collection. Who is using that?
context is a collection in NodeBB and Streams, at least. Its usage is described in FEP-7888 (whereas usage of the replies collection is described in FEP-7458)
Sadly it seems as if for example Mastodon does only support the replies. And of course it is not practically to query the replies collections of all posts in a thread.
NodeBB and Discourse will support resolvable contexts that can be used to backfill topics. The aim is to replace the current “solution” of traversing inReplyTo.
At current there are no plans for synchronization of topics, but that would be something we could also discuss after an initial proof-of-concept between our respective softwares.
Follow activity needs to be sent to some inbox, but objects don’t have an inbox, only actors do. I think one could create a followable Application actor linked to context collection, or use context as both actor and collection at the same time (though I’m not sure if mixing core types is a good idea).
A context collection could be considered an actor by nature of having an inbox, and so topic following mechanism could theoretically be achieved through that.
But I feel like a more natural activity would be to have the Follow activity sent to the instance actor, with the context sent as the object (or maybe target?)
The problem is that to my knowledge there’s no way to discover an instance’s Application actor.
I think these kinds of statements are a bit misleading. They reflect the common microblogging implementation decisions, but may not be the best choice for other kinds of social networking applications.
A Follow activity must be POSTed to an inbox endpoint URL. That endpoint may or may not be associated with a specific actor since it might be a “shared inbox” endpoint. A shared inbox URL endpoint can exist without an “instance actor” (AKA “application actor”). How one would discover a shared inbox endpoint without an actor is not described by AP, but there are multiple ways it could be done (WebFinger, NodeInfo, HTTP headers, etc.).
Any Object can have an inbox property although AP requires an Actor to have the property. Having an inbox property does not make an Object an Actor.
It’s not clear to me that all activities must be “sent” to specific actors when a shared inbox is used. A Follow activity with a source actor and a to-be-followed object URI doesn’t necessarily need any AP recipients (i.e., delivery targeting) to be processed by a server.
Is there some other way to identify actors? One can check type, but this is not a good idea because that will prevent developers from working on use cases where none of the standard 5 types are appropriate.
As far as I can tell, there’s no general way to identify actor types. There’s no actor “class” in AS2 so we’re left with the standard 5 types or a multi-typed Object including at least one of the standard 5 types.
I think this is a shortcoming of the Recommendations, but I’m not convinced that using the presence of an inbox property as an artificial type hint is a great way to compensate for it. One can logically infer that any Object correctly referenced by an activity’s actor property is an actor, but that’s probably not useful in practice (?).
EDIT: As mentioned previously, the AP inbox was based on the LDN inbox concept. In LDN, aninbox can be associated with any RDF resource. Although AP requires an actor to have an inbox property is doesn’t preclude other AS2 Objects from having one as well,.
Yes, that’s not useful because objects may exist independently from activities.
Duck typing actors by the presence of inbox and outbox is useful, and solves a lot of problems. I don’t see any downsides in that
I understand it’s a useful kludge. I just don’t think the actor duck typing should be presented as if it’s supported or specified by the AP Recommendation (for the reasons I’ve described). That’s the downside I see. It looks like a “fallacy of the inverse” logical error. I’d rather see it described as an AP extension that solves problems in some use cases while restricting other valid AP use cases (e.g., other non-actor objects with inbox and/or outbox endpoints).
I agree. With that approach, you can identify actors that act, but you can’t identify completely nonstandard actors that have never acted. This is a problem with the AS2 actor modeling. Maybe AS3 will fix it?
