I might cross-link to Best-practices for AP vocabulary extensions?
Taking from notes I created on fedi challenges to reference a quite old article: The 2010s and alternative Social Media: A decade full of work, hope, and disappointment by Dennis Schubert.
The important thought is that right now “ActivityPub et al is a Framework” and not a comprehensive spec where you can say to someone: “Here’s the spec to implement AP and let’s interoperate”.
Dennis wrote:
What I got was the exact opposite, and in a way that I found quite shocking, to be completely honest. Several folks who worked on ActivityPub, ActivityStreams, and other more or less related specifications reached out to me and told me they agree with pretty much everything I wrote. In general, people familiar with specifications and interoperability agreed that ActivityPub is less a specification for an actual protocol, but more a framework, which opens options for further dialects to be worked out, and specified on their own. Some implementors agreed with this statement, saying it is quite painful to implement these specs because there is no “source of truth” to work from. […]
The tamest reaction out of all was an article published by an organization [Feneas, now defunct] that claims to “spread knowledge about federated web projects and help people and projects involved in this area”, where one implementor took the time to take all my points and explain how you can work around those. The overall resentment of this reply was “you can implement ActivityPub just fine, you just have to talk to every single other implementation to make sure you are compatible”
That reference to AP being a framework is touche on in a previous article by Dennis Schubert where he explains What ActivityPub is.
And a last point to mention is that, when extension mechanism is clearly defined and intricate part of the specification itself, one might discover extensions on the fly… anyone can create extensions, anyone can discover them and integrate with them. I was hinting at that in my best-practices post (top link), but it was nicely described by @cjs in yet another old article An ActivityPub Philosophy:
"Why not build on top of ActivityPub to solve both of these problems?
First, we as a community create an ActivityStreams extension and define behaviors to document the specifications built on top of ActivityPub. We now have a way to store ActivityPub extension specifications in the Fediverse itself. Next, building an application server that understands this extension and can federate it over ActivityPub means anyone can simply host an instance, allow users to register, build its community, and be free to draft new specifications on top of ActivityPub. Since this data is then federated by ActivityPub itself, it is reachable by both technical and non-technical users. There is neither a central authority nor a central registry as each community is responsible for its own ActivityPub specifications. This is the democratization of ActivityPub across all domains. People cannot have their ActivityPub extension specification censored. As long as the core ActivityPub protocol as currently written is followed, federation compatibility naturally leads to new domains and apps implementing them."
I feel that if an ActivityPub 2.0 would bring back those clear distinctions of transport protocol, social data syntax and extensibility mechanism (linked data based), then v2.0 might constitute a significant simplification.