If Actor @Alice@A has one follower @Bob@B, then addressing a message to Bob’s inbox means the message is sent once. But when Bob’s friend @Rob@B also follows Alice, the next post addressed at followers will be sent twice by default. Taking up twice the bandwidth.
I understand that the sharedInbox is meant to solve this, but that there’s some contention over how it’s specified or implemented…? Under which circumstances is the sharedInbox used? Can a receiving server opt to use it exclusively (or would that break interoperability with existing systems)?
If you find the sharedInbox problematic, can you explain your issues with it and how it might be improved?
Don’t use shared inbox unless you want to support instances of tens of thousands of users, and even then there are other ways to scale. As I understand, it was only introduced so that Gargron could easily scale his flagship instance.
It’s the only ActivityPub feature that breaks the Actor model. If you don’t give Actors their own inbox, then you’re doubling down on breaking the Actor model. I don’t recommend breaking the actor model.
Edit to add: convention is some software supports shared inbox, but all software supports the Actor model.
For me, there’s no difference between the two kinds of inboxes on the receiving end. They’re literally handled by the same function. When sending, however, I usually send activities that are only intended for one user (Follow, Like, etc) to their own inbox, and activities that are public, like Create, to the shared inbox if available. I deduplicate inbox URLs so if there are multiple actors on the same server that doesn’t have a shared inbox, I’ll end up sending as many copies of the same thing as there are target actors on that server.
If one were to follow the spec letter-to-letter, then it could become possible for different actors on the same server to have different views of the same object (e.g. one user did receive a Like, but another did not). In practice, I’ve yet to see a project that would implement its database to do this.
Most implementations have a UI-centric database schema and all the ActivityPub concepts only exist for the purpose of server-to-server communication. As in, no one (I know of) is actually storing an inbox or outbox as a list of activities, and AP objects are generated on the fly from available data whenever needed.
I’ll implement both kinds for maximum compatibility, I guess
While I find it noble and good in general to stick to the model, performance takes precedent for me in almost all cases. From that perspective it seems wasteful to send several more copies of a message than needed.
This is one of the few times you’ll see me agree with @cjs, but sharedInbox is underspecificed, buggy, and prone to desynchronization issues. It makes sense for some type of content, and it’s unavoidable when you’re talking about accounts like Gargron who have up to half a million followers, but I think it’s good to avoid relying on it, because it can introduce surprising and hard to debug issues in your application when two servers disagree on what members a collection has (among other things).
