Idea: Crowdsourced Reference Implementations to Standardize Protocol Extensions

I sent a ShowerThought on fedi about AGPL-like licensing for protocol extensions, which was not a good idea, but in the thread @LibreSolutionsNetwork mentioned using reference implementations instead [of FEP / AP protocol extension docs] to demonstrate new capabilities. And these can be AGPL-licensed to encourage they remain open and maintained as further changes are made.

Quoting Libre Solutions Network:

  • Create reference implementations of specific features in major languages
  • License those implementations as GPL
  • Encourage app developers to contribute their extensions as reference implementations.

If steps 2 & 3 can start rolling forward it could be very powerful.

On Matrix I discussed a bit more and pinged @dansup as this idea may align with FediDB’s future plans.

Musing a bit further about this idea, below some thoughts…


Allow federated app developers to demonstrate ActivityPub extensions in code in their familiar language, instead of asking them to write formal documentation (a process that in practice doesn’t happen or stalls).

The code serves as reference implementation of particular capabilities / features that are added to the protocol.

Other developers may hone and improve the snippets, or provide additional alternatives written in their language of choice.


There are many ways to offer this. Here’s some ideas:

  • A webapp that allows submission of reference impls with a basic UI.
    • A minimum amount of metadata is required to present submissions to other devs.
  • Service that allows simulation of message exchange patterns that’d trigger the capability in the reference impl.
  • A Codepen-like online editing environment might be available to, either:
    • Write glue code that invokes the proper behavior in the federated app itself.
    • Or just contains test code that generates the expected responses directly.
  • A Gallery-like UI might present the submissions of reference impls in neat fashion.
    • Gallery is like a pattern library that can be easily navigated to find specific capabilities.
    • If later on formal FEP’s or AP extension docs are created they can be tied in with the impls.
  • Code is stored in a git repository with copyleft license, and PR’s can be made to it directly.


Documentation is a chore. There’s a barrier to do it and do it well. Devs generally prefer coding to writing docs. They are proud of what they built and are incentivised to showcase that. If their extensions are more broadly adopted their project would benefit.

Other devs who want to adopt an extension can quickly see the inputs and expected outputs. They can follow the message exchange easily. While adopting they can first testdrive compatibility by writing code in their own language in the same environment, using it as a test harnass. Once done at the same time they have added an alternative reference impl to Gallery / pattern library.

Further incentives are provided by a clear attribution to the authors of the reference impls. Also having things come together in a single Gallery they are no longer dispersed across the web and very hard to find. Each dev can add references to their own codebase and other resources that are relevant when other want to adopt similar capabilities.

1 Like

Why was it not a good idea?

The primary problem I have, as a developer, is the absence of reference implementation for ActivityPub itself, as well as a robust test suite to check the conformance of an implementation of the protocol. I would need that to be available before I can consider working on extensions or even using them.

My 2cts

1 Like

Protocols cannot be subject to copyright apparently, and even if they were then licenses would offer no guarantee that upstream specs would be updated indeed. And if they are not, then the stick that licenses offer is a legal procedure. But that is not a stick that is fitting for the free software community.

Yes indeed. The scope of this topic encompasses all that. @dansup is working on very interesting tools that can help here, and we discussed in the Social Coding Foundations chatroom. The above provide some further ideas that may or may not be feasible to consider.

1 Like

Thanks for clarifying: I thought the license was for the reference implementation but that’s not what you wrote, sorry for the noise.

1 Like

Fun part is that with reference impls licenses now do become an option to ensure that stuff becomes available for use upstream :slight_smile:

1 Like