Grassroots open standards for fediverse evolution

Click to expand alt-text for the image with the TLDR summary of the blog post.

Pillars of Grassroots standardization

I would like to thank @silverpill and @evan for their tireless work on respectively the FEP Process and W3C SocialCG.

Article summary

  • Grassroots growth has seen the fediverse gradually diverge from ActivityPub open standards.
  • With post-facto interoperability the dominant driver, increasing protocol decay hampers innovation and growth.
  • Fediverse as it stands today has limited its application areas, and lost attractiveness to newcomers.
  • A shift back to open standards is possible and required for ActivityPub to remain relevant in the future.
  • Current technology standardization process is unfit for the social dynamics in fediverse grassroots environment.
  • Challenges to standardization are fostering shared ownership, proactive involvement, governance, and recentralization.
  • There are four points where recentralization is a risk: server instances, app platforms, the FEP process, and W3C SocialCG.
  • While funding is available for individual FOSS projects, it is lacking for any work on healthy technology ecosystems.
  • Grassroots open standards allow specification documents to evolve from the bottom up in inclusive commons based ecosystems.
  • Grassroots standardization aligns top-down protocol design with innovation in the creative cauldron of the commons.
  • The social web offers opportunities to natively support standardization processes, and decentralize specifications.
  • Specifications as code that may be bundled with their apps and services, and can be introspected at actor endpoints.
  • Decentralized specification hubs can serve the interoperability needs for different interest groups and solution domains.
  • FEP may become the fediverse evolution process and be part of protocol design that enables robust solution development.
  • Work on the ActivityPub API offers opportunity to reposition the FEP as federated service for Grassroots standardization.
  • With ActivityPub as a grassroots standard, fediverse can be the Future of social networking where we Reimagine social.

See also:

For understanding the power of Emergence and how it relates to going “Back to standards” see…

ActivityPub, the Good, the Bad, and the Ugly

I did a DuckDuckGo search to find if other people than me also specifically mentioning protocol decay in relation to ActivityPub vs. fediverse installed base. DDG’s AI Search assist gave a good response, which referenced among others the blog by Dominik Chrástecký…

Who says in the Conclusion of the article…

Conclusion

ActivityPub, particularly its vocabulary rules (ActivityStreams), remains a half-finished protocol. Its effectiveness depends heavily on individual implementation choices, creating problematic discrepancies—such as the inability to reliably send private messages between Mastodon and Lemmy users. Moreover, simple human errors or software oversights can unintentionally expose private information, as recently demonstrated when new Fediverse software mishandled Mastodon-style private messages and displayed them publicly.

The solution? ActivityPub needs a clearly defined second iteration—an ActivityPub v2—that eliminates ambiguity, standardizes behaviour strictly, and provides essential security measures. Certain issues, especially privacy, may never be fully resolved within the protocol, but increased clarity and stricter rules would significantly mitigate existing risks.

This doesn’t mean we should abandon ActivityPub, but rather, we must work collectively to standardize it further, making it more secure and less error-prone.

Which corresponds with the observations I made in my “Grassroots fediverse evolution” blog post. In the section on “The Bad” the author formulates matters of protocol decay as follows…

The Bad

Most issues with ActivityPub stem from one critical flaw: much of its behaviour is undefined. The core types and activities allow interactions that make little practical sense. For instance, the Like activity should be simple—you like something. But, in ActivityPub, you can “like” another Like activity, creating infinite loops of nonsensical interactions.

This flexibility leads to a significant problem: no two implementations behave identically. Developers resort to hacks and guesswork to interpret undefined behaviour. Ideally, ActivityPub would strictly define interactions for core types, enabling implementations (Mastodon, Lemmy, Pleroma, etc.) to focus solely on presentation or extending functionality, knowing basic interactions remain consistent across platforms.

Botiquette-related protocol decay