The success of federated social networking requires a widely adopted common protocol for server to server communication. If we ask today "which protocol", it's clear that ActivityPub (AP) must be considered, as nearly all communities with 100 or more servers listed on the-federation.info use software that implements the protocol.
AP has seen wide adoption and is increasingly being chosen by new federated software implementers. This building momentum is based on the effort and energy of a broad and decentralised movement that wishes to challenge the current paradigm of online social networking.
However, like its predecessors, OStatus and Pump.io, there is criticism of ambiguity and negligence in the specification. Diaspora* (251 servers, 684,294 users) developers have so far declined to implement AP citing ambiguity as their main concern. The "Security Considerations" section is marked in its entirety as "non-normative" and for implementers this has come to mean: "figure it out yourself". Some have understandably reacted with dismay: "can we just delete the entire Fediverse, try again, and actually care about security this time?", @puckipedia@puckipedia.com.
AP implementers are faced with numerous difficulties. Attempting to encode the ideas of a community's notion of social interaction with such ambiguity can result in an incompatible dialect of AP.
While diversity of AP implementation will always be a fact due to the differences in software, the incompatibilities in messages passed from server to server may result in a failure to uphold expectations of trust and privacy.
For example, if a content privacy policy specific to one community must be implemented and the AP specification does not provide a formalised way to describe it then the policy may not be honoured when messages arrive at another server. Private messages may be treated as public messages.
The opposite is unfortunately also possible: privacy requirements of one community can be considered dangerous by another. As explained by @kaniini@pleroma.site in "The Case For Blind Key Rotation", activists who require plausible deniability are at risk when implementations require irrevocable authentication signatures.
Proposals for improved security measures are already being discussed. The efforts of @cwebber@octodon.social's work in progress "PolaPub" document, the OCAP-LD W3C draft and @kaniini@pleroma.site's "What would ActivityPub look like with capability-based security, anyway?" suggest a backwards compatible approach to delivering a well established and powerful security design.
A promising vision of such a process is described in "ActivityPub: Good Enough for Jazz" by @jdormit@mastodon.technology where a parallel is drawn between the development of HTTP and AP: a community consensus process which can deliver improvements to the protocol.
However, with the W3C reputation in question (approval of digital rights restriction recommendation scandal) as well as new focus on the SOLID platform, it is not clear whether they'll play a central role in the next iteration of the protocol.
Online forums such as socialhub.network are creating a space for such discussions and the possibility of a community-based "ActivityPubConf" is already on the horizon.
Despite the unknowns and in opposition to the walled gardens of the Twitters and the Facebooks, the federated social networking project continues to show great promise. As @cwebber@octodon.social warned us in the closing of the FOSDEM 2019 ActivityPub panel: "The Fediverse is people, it's people!".