The big thing is that this is a network comprised of Actors. An Actor is usually a Person, but it can otherwise be an Organization or a Group. Actors perform Activities on Objects - generally, these interactions can be represented in a stream of some kind.
In the ActivityPub world, Actors have an Inbox for ingesting subscribed content (activities and objects from other actors), and an Outbox for dispatching their own stuff, which is then sent out to a collection of Followers. Most implementations have a notion of permissions, in the sense of who is allowed to parse or even receive an Activity.
Of course, the protocol and implementations go way deeper into that, but this is the general gist of how ActivityPub is supposed to work.
It helps a bit to understand the actor model and realize that activities are messages being passed to an actor.
Sadly AP breaks the actor model *caugh*because Mastodon*caugh* but otherwise it fits the model pretty well and thus could use an alternate transport such as what @pukkamustard is doing.
In an Actor model system, messages are sent to an actor.
In ActivityPub, sharedInbox breaks the actor model by placing work on the server to filter on whether or not the message should be delivered to the recipient, rather than sending it to multiple recipients.
This violates the principle in an actor model system that an Actor should be the computational unit of work.
The right (tm) way of handling this IMHO is to either not offer a sharedInbox or else to have a special Actor called _all whose job it would be to decide who to deliver to, but by using this concept called a sharedInbox, you violate that principle.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!