To get back to the original subject: Do we have a 2-stage vs. 3-stage rocket to standardization?
Standards Process
I’m absolutely with @eprodrom that forks should be avoided. Instead there must be more clarity on correct use of both ActivityPub and ActivityStreams, to ensure that implementations converge towards interoperability, not tech debt.
Our current situation in practice is worse than forking, and entails individuals hard-coding flavors of the protocol and not even realizing they introduce Protocol Decay (see RFC-9413). They say “we are part of the Fediverse now”, but only a tailor-made integration allows others to interop.
So AS/AP must provide a solid foundation to build upon. Call it the “core protocol stack” or something like that, which gives federated solutions the means to communicate securely and comes with just enough functionality that any social networking project must take into account.
The AS/AP et al standards MUST provide the minimum requirements for network connectivity.
Then there’s there’s the notion of ActivityPub (by means of Linked Data and ActivityStreams) as a pluggable protocol, where the extension mechanism allows anyone to model extensions for their domain and use cases. This provides federated solutions the means to understand each other, i.e. achieve various levels of interoperability. For this part, imho:
The Standards Process MUST provide clear pathways to ever increasing compliance levels.
We have some mechanisms in place, but they are insufficient. Here we can offer improvements.
Extension mechanism
AP Extensions are message formats (vocabulary) plus message exchange pattern (behavior).
For instance the FEDERATION.md, first proposed by @darius and brought to a FEP by @silverpill is great, an improvement, but does not bring more than an appeal to the developer to “please provide this”.
A stronger version of it would allow making a claim of compliance on your API endpoints (e.g. via “Compliance Profiles” or similar mechanism). Just enough functionality to allow 3rd-parties to discover the specs you claim to adhere to and also say “Hey, I found a compliance problem”. Which either leads to a bugfix or an improvemet to the extension specs.
Linked Data extensibility
Instead of “Compliance Profiles” as described above, linked data’s own extensibility mechanism might be sufficient. Imho there needs to be:
- An extension specification indicated by the namespace URL. Following the URL gives you the specs.
- Best-practices to move away from app-specific namespaces.
On the second point one best-practice is indicated in @eprodrom’s draft extension policy: move common formats + behavior to AS2 Extension Registry.
Imho this should only be done if the vocab addition truly belongs in the “core protocol stack” i.e. part of minimum requirements for connectivity. Not doing so would turn the vocab into something like schema.org, a huge ontology with abstract names where 99% isn’t relevant to your use case and still people use all the terms with different semantics and behavior.
Converging towards interoperability
Imho the Standards Process should do everything to encourage convergence into domain-specific profiles. It should provide easy pathways for decentralized developer hubs to emerge and collaborate on extension specs that define the common denominator of functionality in their particular domain / app-type.
Take for instance Microblogging:
-
No convergence, and my app’s
@contextwill list N different microblogging apps custom namespaces, OR (and more likely) it will list the namespaces of the giants in my domain (e.g. Mastodon). And then I add my own custom namespace that the other implementers may take into account, or not. -
Microblogging apps create a Microblogging community to work on specs. Or they be part of a Moderation working group (e.g. IFTAS). An app developer’s
@contextnow points to the common extension spec maintained by these hubs. Plus their own custom namespace for app-specific stuff.