Update: https://codeberg.org/fediverse/fep/pulls/851

I think the FEP now better explains why side effects must be explicit:

A generic server can only carry out the side effects of basic activities. Therefore, clients MUST specify the side effects of all other activities as additional activities. Clients can embed them into an activity using the result property, or send them separately.

Is there more than the list of 5 basic activities that can be considered generic, I wonder? Perhaps it might make sense to describe what a generic server supports, in the form of Use Cases, in a similar way as the motivational use cases in the ActivityStreams vocubulary spec. Then for each use case a consistent pattern can be specified that MUST be implemented (either refer to AP spec if robustly defined there and/or add additional info on format, behavior, msg exchange).

Adding examples: https://codeberg.org/fediverse/fep/pulls/909/files

I think Follow-Accept could be broken down into Create(Relationship) and Add activities.

I think the FEP should provide an example of following an actor. But I don't know yet how the sequence should look like