How to subscribe to a thread?
-
How to subscribe to a thread?
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
So here is an alternative: FEP-f06f: Object observers.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast
AddandRemoveactivities that have thread collection as theirtarget. Observer's followers will have an up-to-date view of the thread. -
How to subscribe to a thread?
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
So here is an alternative: FEP-f06f: Object observers.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast
AddandRemoveactivities that have thread collection as theirtarget. Observer's followers will have an up-to-date view of the thread.@silverpill@mitra.social I think given the addressing limitations of collections, this by-proxy method of determining who to send an
as:Followto makes sense as a stopgap measure until ActivityPub's next version... -
@julian If these limitations don't prevent us from implementing any features, why they should be addressed?
The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.
-
@julian If these limitations don't prevent us from implementing any features, why they should be addressed?
The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.
@silverpill @julian how is "the entire network built around the idea"? why do you have this idea of an actor that necessarily maps to a user?
from https://www.w3.org/TR/activitypub/#actors we see that:
> ActivityPub does not dictate a specific relationship between "users" and Actors
so why introduce the concept of "observers" and then prevent users from knowing what they are following? Why the avoidance of calling a conversation a Conversation, and why the artificial limitation of not being able to follow one?
-
@silverpill @julian how is "the entire network built around the idea"? why do you have this idea of an actor that necessarily maps to a user?
from https://www.w3.org/TR/activitypub/#actors we see that:
> ActivityPub does not dictate a specific relationship between "users" and Actors
so why introduce the concept of "observers" and then prevent users from knowing what they are following? Why the avoidance of calling a conversation a Conversation, and why the artificial limitation of not being able to follow one?
@trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal
Applicationactor is recommended, which is not a "user".The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.
-
@trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal
Applicationactor is recommended, which is not a "user".The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.
@silverpill @julian Yes, you've said as much in those discussions, but everything you've said depends on this idea of an "actor" that isn't coherent. On one hand, you seem to be arguing that outbox+inbox is all you need to duck-type an actor, but then you don't actually do anything with this concept of an actor except saying that "it can perform activities". So an actor is the range of the `actor` property? Okay, so what? No behaviors depend on this. It is a tautological definition.
-
How to subscribe to a thread?
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
So here is an alternative: FEP-f06f: Object observers.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast
AddandRemoveactivities that have thread collection as theirtarget. Observer's followers will have an up-to-date view of the thread.First, one wants a mechanism to subscribe / unsubscribe to a conversation. Having an actor manage it, is a better mechanism than turning the conversation object into a quasi actor.
I have misgivings, because:
- The point of using acct-uris is to be more human readable. If one needs to generate them automatically for each thread, this will degrade quickly. IMO it would be better to drop the requirement on webfinger.
- Generating an observer for each object will lead to a lot of generated public / private keys. I'm not a fan. It would be good to address this somehow. Not sure what the ideal solution would be.
-
First, one wants a mechanism to subscribe / unsubscribe to a conversation. Having an actor manage it, is a better mechanism than turning the conversation object into a quasi actor.
I have misgivings, because:
- The point of using acct-uris is to be more human readable. If one needs to generate them automatically for each thread, this will degrade quickly. IMO it would be better to drop the requirement on webfinger.
- Generating an observer for each object will lead to a lot of generated public / private keys. I'm not a fan. It would be good to address this somehow. Not sure what the ideal solution would be.
1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.
2. I think observers (and other Application actors on the server) should use a shared key.
