ActivityPub/Primer/Out-of-order activities

Some activities refer to other activities; see ActivityPub/Primer/Referring to activities for details.

Delivery of activities is not serialised. In particular, many ActivityPub implementations queue outgoing and incoming activities, so there is no guarantee that an activity will be processed before activities that refer to it.

A naive receiving server will ignore an activity that refers to an unknown activity, and then may process the initial activity when received later. For example, if a server receives an Undo of id abc123 (which it hasn't seen before), and then afterward receives a Follow with id abc123, one possible behavior is to discard the Undo, and when it gets the Follow, it would be valid and processed as usual.

For this reason, to accommodate out-of-order delivery:

• The sending server should make an effort to serialize activities; in particular, not sending activities that refer to another that has not yet been sent.
• The receiving server, if it receives an activity that refers to an unknown activity, should store that activity for later processing. A limited time period for storage of unprocessed activities is preferable; 30 minutes should be sufficient in most cases. In order to avoid storage overflow, the receiving server should keep the storage of unprocessed activities bounded.