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.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. 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:Follow to 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.
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.