I got around to reading the ActivityPub spec. and it's pretty nice! I'm wondering how implementations decide when to create a shared inbox. Seems like a potentially interesting algorithm.
@NicolasConstant @cwebber Sure, but in what circumstances would a shared inbox be created?
Thanks Nicolas, but I'm still not understanding something about the lifecycle of a shared inbox. I've probably got a bad assumption, so please help me.
Let's try an example. Suppose three users, A, B, and C on the same instance follow users D and E (on other instances like this:
* A follows D
* B follows E
* C follows D and E
Then A and C can use a shared inbox (for posts from D) and B and C can use another shared inbox (for posts from E), but it wouldn't be valid for A, B, and C to use a single shared inbox since A would then receive E's posts and B would then receive D's posts. Right?
At some point, someone or something has to decide when to create a shared inbox and it presumably has to satisfy the kind of constraints in the example above. Who or what creates a shared inbox and at what point?
Thanks, that's very helpful. I appreciate you taking the time to clarify things.
Just to finish off, please could you clarify how many shared inboxes there typically are in a given instance? I'm presuming one, which will be created automatically by the instance implementation and which will be added to (the endpoints mapping in) every Actor object transmitted from the instance.
@underlap Note that I have the unpopular opinion on the fediverse that sharedInbox was probably a design mistake, not for having an aggregate point, but for assuming that receiving servers do their own routing heuritics instead of looking at explicit addressing. I have written some alternative proposals on this but I forget where. It's my biggest regret about ActivtyPub.
That said, I appreciate @NicolasConstant explaining the reality we have, since I did not have time or energy to revisit :)
Oh I see. In fact it's way more simple and shared inbox doesn't rely on the relational graph (at least on current implementations), but more on a usage context.
With your example, it is valid that A B and C share the same shared inbox (it's the current implementation) : but something ending in the shared inbox is not always dispatched to all the users relying on it.
Lets say D publishes a public post (and is transmitted via the shared inbox), A B and C can access it, and it will display in A and C timelines (or equivalent).
Lets say D publishes now a follower-only post (still on shared inbox), B will ne be able to access it, nor seeing it in their timeline (or equivalent). Others will.
Lets say shared inbox is just a way to share data, analysis and routing must be made afterward.
If we didn't have shared inbox, we would have to post the same content to each followers. It's just an optimization.