What Is an Inbox in a Federated Social Protocol?
From the earlier reference collection. Read the current software blog.
An inbox is a receiving endpoint associated with an actor or server in a federated protocol. Understanding delivery, validation, and duplicate handling explains what an inbox does and does not promise.
A receiving address for activities
In a federated social protocol such as ActivityPub, an inbox is an endpoint where software can deliver activities for processing. It is associated with an actor or a broader server role, depending on the protocol’s model and implementation. It gives senders a destination; it is not simply a user’s email folder.
A sender typically discovers the relevant endpoint through protocol data associated with the recipient. The sending server then makes an HTTP request carrying an activity. How that endpoint is authenticated, validated, queued, or exposed to the user depends on the surrounding protocol rules and implementation.
Receiving is a processing pipeline
An inbox handler should not assume that a request is valid merely because it arrived at the endpoint. The server may need to check the message structure, verify its origin or signature according to its design, apply policy, and decide whether the actor or recipient is acceptable. It may then enqueue work so a slow downstream task does not hold open the network request.
For example, a server receiving a Create activity can validate enough information to accept it, store the activity or its identifier, and schedule the object for further processing. The user interface might update after that work completes. A network-level success response and a visible post are separate events.
Delivery can be retried
Distributed systems encounter timeouts and temporary failures. A sender may retry when it cannot tell whether the receiver completed the first attempt. That means the same activity can arrive more than once, even when the sender is acting correctly.
The receiver should recognize stable activity identifiers and avoid applying the same side effect repeatedly. If processing is queued, record the identifier durably with the accepted work so a restart does not erase the duplicate check. The exact retention policy is an implementation choice, but the underlying duplicate problem is general.
Treat inboxes as protocol boundaries
An inbox is a boundary between remote input and local state. Validate data, limit resource use, preserve enough information to diagnose failures, and handle retries deliberately. Do not expose private data merely because a sender can name an endpoint, and do not assume every activity should be shown to every user.
For operators, useful logs distinguish receipt, validation, queueing, and final processing. That makes a delayed or rejected delivery easier to trace. Thinking of the inbox as a carefully managed interface helps keep federation behavior reliable and understandable.