Programming · free software · the open webSubscribe via RSS

How Does ActivityPub Deliver an Activity?

From the earlier reference collection. Read the current software blog.

Activity delivery connects an actor’s action, its addressed recipients, a delivery endpoint, and receiver-side processing across separate servers.

An activity starts with an actor

ActivityPub models interactions as activities associated with actors. An actor might create a post, announce an item, or perform another action represented by an activity type. The activity carries information about the actor and the object or action involved, along with addressing information. Creating that representation is only the beginning: delivery is the process by which relevant remote systems receive it.

Determine who should receive it

The sender considers the activity’s recipients and determines which remote actors or collections are relevant. A recipient may be local to the sender’s server or hosted elsewhere. The sender’s software needs to resolve remote recipients to the appropriate delivery destinations using protocol data and server knowledge. The exact routing details depend on the implementation and protocol requirements; an activity’s audience should not be confused with a guarantee that every intended person has read it.

For example, when an actor publishes an update addressed to a set of followers, the server may need to identify follower actors hosted on other servers and deliver to their servers. A local follower can be handled within the same service. This distribution step is distinct from composing the activity itself.

Send and process at the receiving server

The sending server transmits the activity to remote delivery endpoints using the protocol’s supported mechanisms. The receiving server then checks and processes the incoming activity according to its rules. It may validate the sender, determine whether the activity is acceptable, store relevant information, and make it available to local users or downstream processing. A successful network request does not by itself prove that every recipient displayed the activity or that a person saw it.

Because servers operate independently, delivery can fail temporarily or arrive more than once. A robust implementation records enough state to retry appropriate failures and to avoid treating a repeated message as a wholly new action. Authentication, authorization, and policy checks remain part of receiver processing.

Keep each stage observable

When diagnosing a missing update, ask where the chain stopped: Was the activity created? Were recipients addressed as intended? Did the sender resolve a remote endpoint and attempt delivery? Did the receiver accept and process the request? Separating these steps helps distinguish a composition error from routing, network, or receiving-policy behavior. ActivityPub delivery is therefore a sequence of decisions across servers, not a single global broadcast operation.

Suggest a correction · All posts