A shared inbox is an ActivityPub endpoint that can receive activities for multiple actors on the same server. It lets a sending server deliver one copy of an activity to a remote host instead of repeatedly POSTing the same activity to many individual inboxes there.
One endpoint for many local actors
ActivityPub actors can advertise an endpoints object containing a sharedInbox URL. Imagine one post addressed to 500 followers on the same remote Mastodon server. Without shared-inbox optimisation, the originating server may need hundreds of nearly identical deliveries. If the remote actors expose the same shared inbox, the sender can group compatible deliveries and send the activity once. The receiving server then determines which local users should see it. This is a transport optimisation; the activity's addressing still controls the intended audience.
Why it matters at scale
The saving becomes significant on large networks. Federation fans one local action out across many independently operated servers, and redundant HTTP requests consume connections, queues, CPU time and bandwidth on both sides. Shared inboxes reduce that duplication without introducing a central relay or changing who ultimately receives the activity. They are one reason ActivityPub can scale better than a naive 'one network request per follower' interpretation would suggest.
Privacy and optional support
Shared inboxes are optional, and senders still need to respect privacy and addressing. An activity should not be collapsed into a shared delivery if doing so would reveal recipients or content to a server that should not receive it. Implementations may also choose not to use the optimisation. The endpoint reduces network work between servers; it does not make private messages private from the administrator of the destination server.
Related reading
- What Is NodeInfo? The Metadata Standard Used by Fediverse Servers
- What Is WebFinger? How ActivityPub Finds Accounts Across the Fediverse