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 :)
QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.