I've been experimenting with creating an ActivityPub test suite for two of the three conformance specification profiles in the ActivityPub (AP) specification: ActivityPub conformant Server (server-side of client-to-server specification) and ActivityPub conformant Federated Server (server-to-server).
As I run this test suite on various servers it's appearing to me that (probably) no server is compliant with the ActivityPub specification. It's not completely surprising. Being compliant with the specification would be very challenging. Most developers are understandably more interested in interoperating with existing, popular non-compliant applications than being compliant with the specification.
When I say nobody implements ActivityPub, I don't mean that they don't implement all of it. The multiple conformance profiles and many optional parts of the specification make it clear that the specification authors intended that developers pick parts to implement that are useful for their specific application. What I'm saying is, for the parts they implement, no server appears to be compliant with the specification. Maybe that's fine. This is an observation, not a judgment.
Before giving a few examples, let's review the AP specification context a bit more. The ActivityPub specification builds on the Activity Streams 2.0 (AS2) and Activity Vocabulary specifications. The Activity Vocabulary documents an informal ontology describing activity types and related entities (Actors, Objects, Collections, etc.). The vocabulary specification also describes properties that can be associated with the entities.
ActivityPub uses the Activity Vocabulary as its foundation and extends it with extra properties like "inbox" and "outbox", among others. The specification stack looks like this:
In the Activity Vocabulary, properties are defined as being functional or not (the default). Defining a property as functional means that for any given instance of a class or concept, there can be only one value associated with that property. Inversely, a non-functional property can have multiple values. Properties like href in a Link are functional and can only have a single value. Properties like type, actor, object, target are non-functional and can have multiple values.
The Activity Vocabulary specification is very clear about the support for multiple values. As one example, the specification for the actor property states:
Describes one or more entities that either performed or are expected to perform the activity. Any single activity can have multiple actors.
Activity Vocabulary
I haven't seen any code that implements support for multiple actor, object, target properties (among many others). Many servers also don't support multiple type properties, which is a key requirement for Activity Vocabulary and ActivityPub extensibility.
For non-functional properties that refer to other objects (versus primitive values), the JSON-LD value might be a string, a mapping, a Link, or a collection of strings, mappings, and Links. Very few server implementations support all those representations. Even the implementations that are able to process the JSON-LD data are not likely to process the results in a compliant way. Part of the reason for this is that it's not clear to most developers how to do that. For example, how does a server handle authentication and authorization for an activity with multiple actors?
The reality is that developers have understandably taken the path of being interoperable with existing non-compliant applications. I believe part of the reason the established, popular applications are non-compliant is that the specifications would be very difficult to implement in a compliant way.