In the past, you have been somewhat critical about the development of ActivityPub. Could you illustrate on what your criticisms are, and why you feel that way?

As far as protocols go, ActivityPub is a poor quality specification. This is unfortunate for a protocol with such high expectations, coming from an organization whose only function is to produce working specifications for the web. The places where we needed guidance to produce interoperable products (such as privacy and encryption and signatures and even allowed message content) were left undefined or poorly defined.

A diagram illustrating ActivityPub’s basic concept.

Many of the things that were specified with any precision turned out to be things that are critical to interoperation and cross-federation of existing web services and the specification restricts the ability for them to interact in some fundamental ways. If the protocol solved any existing problems there might be a good reason for projects to adopt it, but it doesn’t solve any problems that we don’t already have better solutions for.

I was asked early on in the protocol development what specific use cases I’d like to see covered. I answered with several use cases involving nomadic identity and cross-domain decentralized access control. I was met with “Right. That isn’t going to happen. Come up with some realistic use cases.” The point is, I already have solutions for my use cases. If my customers’ needs don’t matter in the design of a protocol and somebody is soliciting my project as a “customer” of that protocol, I can only suggest that this is a complete marketing failure on their part. At the end of the day, I need to provide solutions for the needs of my customers. The same thing applies to every other free web project.

While it doesn’t solve any specific problems for me, I enjoy being able to interact with the rest of the free web no matter what protocol they use. So I implemented ActivityPub as a cross-federation service according to the published spec, at about the same time as Eugen implemented it for Mastodon. We both claim to follow the spec in the areas that matter, yet interoperation in some cases cannot be easily achieved without breaking interoperability with some other service.

The W3C/ActivityPub editors decided that since Mastodon has more potential “users” than any other ActivityPub adopters, Mastodon’s implementation is being praised as the gold standard for interoperability.

Therefore everybody else must bend to the way Mastodon does things, and this shuts off about half of the existing free social web from being able to interoperate over ActivityPub. Mastodon uses some pretty aggressive HTML filtering and has made other implementation decisions which are now being forced on everybody else.

Eugen is a clever developer and I respect him, but he simply does not have the experience and insights into creating global protocol decisions that might potentially affect billions of people and will work equally well for Twitter clones and newspaper publishers and bloggers.

I’m not saying I do either, but the W3C editors haven’t provided a level playing field and I truly believe the specification is now worthless as a unifying force for the free web. We’re probably stuck with supporting multiple competing protocols for some time (years) into the future. This is OK — it is what it is, but any opportunity for free web unification using a common stack has probably been lost. Ironically, I believe this was ActivityPub’s primary goal, and that makes the specifications which restrict the ability to federate seamlessly with other services flawed — critically.

Source: https://medium.com/we-distribute/got-zot-mike-macgirvin-45287601ff19