Skip to content
Social coding commons
Blog

Grassroots fediverse evolution

Diagram shows how the fediverse diverges from open standards, facing non-linear increasing complexity to facilitate interoperability. See the expandable region in the article that provides a detailed alt-text for this diagram.
- 53 min read
Arnold Schrijver
Arnold Schrijver
@smalcircles@social.coop

The ActivityPub fediverse is doing great, right?

But do you know the extent to which the fediverse installed base has strayed from the promise and power contained in the open standards documents? And that it constrains itself ever further into limited application areas, a self-inflicted narrow straitjacket, if we allow this standards divergence to continue? Did you also know that it is essentially only two (!!) people who are the pillars that try to uphold the entire grassroots standardization process, both volunteers? We MUST improve our standardization practices to assure a healthy future for the fediverse social network. This blog post contains a reflection on my past experience and impressions after eight years of doing community work to help advance the social web.

Alt-text to the diagram. Click to expand a detailed explanation.

Interoperability in practice. A chart with a horizontal axis that goes in 2 directions. On the left it moves towards chaotic grassroots growth, and on the right side towards open standards adoption. The Y-axis indicates level of complexity. The center indicates a low level of complexity.

On the left side of the axis we first find the ActivityPub open standard, with a relatively low complexity level. However the prevailing method to evolving the ecosystem is driven by post facto interoperability, where tech debt and protocol decay is introduced and accepted, which must be refactored and evolve alongside the open standard. Since this doesn’t happen, the fediverse grassroots environment is shifting more to the left into non-lineary increasing accidental complexity. Deviating more and more from the ActivityPub standard and the promise that it holds to offer the Future of Social networking.

On the right side, to contrast against fediverse, we find the Solid Project led by Sir Tim Berners-Lee, which is based on a whole range of W3C Linked Data related open standards and draft documents. There is no grassroots movement that drives progress, but a steering committee. Progress is restrained by open standards adoption and support. Higher levels of interoperability require more rigour and formal standardization, and this also leads to non-linear growth of, in this case, engineered complexity. Solution developers have to wait for many standards to mature, leading to inertia. Solid’s upfront design approach suffers from the chicken/egg problem that lack of standards support withholds developers from technology adoption that increases standards support.


Contents

Section titled “Contents”

Fediverse today

Section titled “Fediverse today”

I’ve talked much over the years how post-facto interoperability as only work method for evolving the fediverse, and not catching up to refactor tech debt and protocol decay, effectively amounts to a Big Ball of Mud anti-pattern.

The FEP Process is an attempt to collect cases of protocol decay and avoid tech debt by recommending common practices to adopt, have convergence on best-practices. But a FEP is merely informative and only works after the fact. The FEP Process is a big success, but also it is a best-we-can-do, a bandaid.

Without proper standardization process the ActivityPub fediverse isn’t able to be the Future of social networking.

A good Grassroots open standard has to find the sweet spot where implementation and specification evolve in lockstep with each other. This article delves into some of the major challenges, and proposes Grassroots open standards as a means to overcome them.

Whack-a-mole development

Section titled “Whack-a-mole development”

Actor introspection for the fediverse has been discussed for years, but never found implementation and common practice, other than out-of-bound mechanisms with Webfinger and NodeInfo that became de-facto standards. Bandaids again.

Today 2026, how does a fediverse developer facilitate the integration with a new or existing fediverse app platform? The best way of course is direct communication, but next come..

  • Find the project website and hope for good quality documentation including design details.
  • Lacking good docs hoping for a good FEDERATION.md in the codebase.
  • Reverse engineer just enough of the codebase to figure out what the project does on the wire.
  • Hope that the project has a valid linked data @context that can be fetched.
  • Hope that all namespaces in @context can be traced to FEP’s or other projects’ specs.
  • Loop over these projects and do the steps above until the requirements are known.
  • Implement the integration, perhaps sprinkle in more extensions, and hopefully document them for others.
  • Continually monitor + fix as new releases of remote dependencies cause breakages in your code.

Decentralized NPM-like dependency hell ensues at scale. Assured to result in a Rube Goldberg fediverse should the fediverse ecosystem see real growth (it is still but tiny today, very small community, loose and fragmented).

In current fediverse a post-facto interoperability leader becomes owner of the parts of the de-facto protocol specs they introduced. It becomes part of their ‘protocol flavor’, a term coined by Helge, an ActivityPub developer who helped improve the FEP process. If a newcomer project wants to offer an interoperable Video platform, they either have to take a dependency on Peertube. Or persuade Peertube to hand over ownership to the FEP Process or even W3C and adopt a shared standard approach. Or, if Peertube is unwilling, force-push their own approach towards post-facto interop leadership, by becoming the most popular choice and new de-facto standard. And perhaps really standardize it later or keep ownership. Rinse and repeat throughout the ecosystem, with all accidental complexity that these anti-patterns cause.

I introduced the term whack-a-mole development (and whack-a-mole maintenance), as the increasing and continuous workload that is incurred by assuring interoperability with remote apps and services on the basis of their moving release targets. A major chore of fediverse development, that also keeps discussions focused on nitty gritty implementation details, and makes fediverse less attractive for newcomers. Rather than higher level ideation and innovation, envisioning the future of social networking, reimagining social and realizing a peopleverse, the fediverse remains a pure technological layer that devs can code to, but is otherwise visionless. It represents a technosphere.

Though there is a measure of resilience against corporate capture that comes with this approach due to how it increases barrier-to-entry, the whack-a-mole situation will become untenable, and both innovation and growth will stall. This is already happening today, where ActivityPub is simply not an attractive choice for technology decision makers, unless they share an interest in the areas of traditional social networking which fediverse grew to support best, with microblogging most prominently supported.

Despite the fondness in FOSS circles to talk about “community”, at ecosystem levels this means no more than “Everyone together. Alone”. With current work methods, fragmented ecosystem, and without refactoring the installed base, my personal opinion is that the fediverse as it stands today does NOT and isn’t capable to represent the Future of social networking. On the other hand the ActivityPub family of open standards does have this potential! This blog post is a follow-up to a #ThoughtProvoker toot I sent earlier on this subject, and my writing about the need for shared responsible ownership of our collaborative ecosystem.

Back to standards

Section titled “Back to standards”

As a GenX person working in IT since 1997 I am lucky enough to have experienced The Good Parts™ of the XML hype cycle. Working in Print publishing at the time at the largest print company in Europe, the range of XML-based open standards that were developed by the W3C, were a real blessing. It allowed us to integrate all the complex systems and third party services that were involved with magazine and newspaper publishing.

Open standards were super relevant, and the W3C website would be checked daily for latest updates. Integrations with remote services could be done by relying on the robustness of the open standard specifications, and focus solely on modeling service interfaces, contract-based development. No need to know the bowels of the remote service, no low-level plumbing and custom development at protocol level on both ends of the interface to get the basics working.

The rise of Web 2.0, with its application siloes and cloud-based SaaS walled gardens, has greatly deteriorated the open standards movement. To such extent that I feel today’s developers no longer realize the true power and benefits of following a standards-based development approach. Instead focus has shifted to pragmatic coding and “show, don’t tell” of working implementations, and small increments. Agile gone rampant.

In FOSS circles, where the typical project management process is loosely based on what a code forge like Github offers, the de-facto development method is “feature-driven design-by-consensus”. Using the issue tracker and merging code increments via pull requests. Over the years software development has turned from Waterfall with too much upfront design, to overly agile where Code is King and good design takes the back seat. Especially in the fediverse developer ecosystem that relies totally on ActivityPub for interoperability, a key enabling technology, typical FOSS work methods are insufficient to mature the technology base. When pragmatically introducing a hack on-the-wire, the whole ecosystem deteriorates.

We MUST find the sweet spot between grassroots development and top-down standardization for ActivityPub to remain relevant as a robust enabling technology for the social web of the future.

Extension is the “killer app”

Section titled “Extension is the “killer app””

An often heard observation by people on the fediverse is that “doing identity right” - having nomadic identities that are not tied to app platforms, and full account portability - constitutes the real killer app that is still missing for ActivityPub to become the social web protocol of choice. And when we only fix this, the fediverse is ready to go mainstream and become attractive to the wider public. I disagree with this notion. That is not the killer app.

While identity is important, there’s a much more fundamental unaddressed problem that ails the fediverse developer ecosystem. Identity of what exactly?

What is the design of your ActivityPub extension? What does it model, which capabilities and services do your AP actors expose? In what way are they interoperable, and thus attractive for other ecosystem developers to adopt? What is the quality of a service design, and how will it mature and evolve? What risks come with adoption of your extension? Do I work with the protocol, or is something app-specific really? For example, has the sole interpretation of a Person actor become that it represents a user account on an app platform? Not in the specs, but on the fediverse it is implied, by protocol decay. Only when knowing the entities and relationships in ones solution’s domain model, can we determine how they map to identity. And more general how app-specific functionality maps to protocol behavior that must be invoked.

Good ActivityPub extension designs based on a robust protocol involve ..

  1. Knowing the business or application domain of the federated solution that is to be integrated with the social web.
  2. Knowing ActivityPub protocol capabilities and interface, but not being bothered by protocol intrinsics.
  3. Knowing message formats with the ActivityPub types and properties to send on the wire, and their validation rules.
  4. Knowing expected response types and message exchange patterns that take place in more involved distributed solution workflows.
  5. Knowing enough of the business logic of the domain to correctly interoperate with remote actors.

Unfortunately up to this present day no good comprehensive guidelines and standards support exist to build robust solutions on top of ActivityPub, and implement good quality, interoperable ActivityPub extensions that follow recommended best-practices.

Remove misconceptions

Section titled “Remove misconceptions”

The presentation “Hammock Driven Development” by Rich Hickey, developer of the Clojure language, should be a MUST WATCH for any FOSS and fediverse developer. The gist of Rich’s message is “neglect the design aspects of your software project at your own peril”. In one of the first slides he mentions that the most costly mistake developers can make, that often leads to complete failure of their projects, is to allow misconceptions to exist on what the objectives are with regards to the solution.

Slide from Rich Hickey's presentation that mentions that "Most of the biggest problems in software are problems of misconception.

On the fediverse we made the cardinal mistake of never taking away misconception from the very start, and instead allowed it to linger and grow, introducing more and more misconceptions over time in the form of leaked abstractions and unclear separation between protocol layer and app-specific coding. And above all we left eternal unclarity to what it even means to be “part of the fediverse”, by the total lack of a shared (technology) vision. Other than saying “It is decentralized, baby” in an Arnold Schwarzenegger voice, we don’t know whether we are creating tomorrow’s Skynet or blissful utopia. We just introduce our own increments to the social web, and tweak until they work with the other apps of the day.

The visionlessness, which long ago I found to be one of major social challenges that ail the fediverse, leads to directionlessness. Or more accurately, the direction of the fediverse is determined by the post-facto interoperability leader(s) du jour: The app platforms that managed to “cross the chasm” and find good uptake of “users” (fedizens) for their app. In a fediverse that represents a technoverse people naturally care more for apps, than for the ecosystem as a whole.

One of the first major misconceptions to address is “the Linked Data conundrum”: The unclear way in which the Linked Data based ActivityPub standard maps to plain JSON implementations, which are also a valid wire format. Despite yearslong discussion and confusion - inherent to misconceptions - there has never been progress to solving the conundrum. This blog article was motivated by a related SocialHub thread I created “Practices around JSON formatting of JSON-LD messages”, where the discussion raged anew.

I will quote @SorteKanin from the thread, who remarked that ..

“Regardless of what side of the debate you are on, you must admit that the controversy around “to JSON-LD or not to JSON-LD” signals a failure of the standards process. Standards should not be controversial. They should seek common ground and thereby eliminate controversy and instead foster cooperation.”

— Source: SorteKanin on SocialHub

Other misconceptions have crept in over time, like many leaky abstractions that are not part of the conceptual architecture of ActivityPub-based social networks, but because of protocol decay must be taken into account now. Think of “server”, “client”, “app”, “user”, “platform”, “instance”, “actor profile”, “post”, and as mentioned above, even “identity”.

It will take concerted effort and prolonged involvement from ecosystem participants to take away these misconceptions, but when done well the rewards will be high: A sustainable path to the future of social networking.

Overcome fragmentation

Section titled “Overcome fragmentation”

In the FOSS and social impact movements values and freedoms are very important and kept in high regard. The culture creates conditions where people are free to experiment, to innovate, encouraged to share knowledge with other people, and autonomously introduce their work. This culture turns FOSS into a rich cauldron of creativity that has huge potential to bring positive societal change.

However not all is well. The value of FOSS has arguably been freely given away, mostly to the benefit of the bad actors. It is not unfair to question complicity of the FOSS movement to the rise of Big Tech and AI technologies that totally disrupt today’s society. There is also validity in people who say “FOSS is for the privileged who are able to spend time and money on it”. Whose more ‘casual involvement’ allow to narrowly focus just on the tech, and shun uncomfortable ethical questions about the externalities of their work.

This complicity however is emergent, arising from countless initiatives that are individually all well-intended. No one can really be blamed. The chaotic grassroots FOSS movement is fragmented in its individual projects, and people are unable to collaborate productively at scale to uphold technology ecosystems. The result is that being involved in FOSS is inherently unsustainable for those who want to earn a decent income from it. To improve FOSS sustainability we must first have realistic expectations. Apart from all the talk on values, what can we expect from FOSS?

FOSS is software code and related artifacts protected by US copyright law.

Period. All the rest, the morals and values, the visions of a better world, and FOSS-based humane and harmonious solutions to get us there, are implied and NOT an intrinsic part of FOSS. Additional social organization and culture must be fostered and nourished around FOSS to provide assurances that lead to more desirable outcomes, and value that flows primarily to the right people in society.

The ActivityPub-based social web, the fediverse, is an unique FOSS-based ecosystem that managed to emerge and forge there own formal technology open standards.

However, if we can’t collaborate at scale, have no time to care for the ecosystem at large, to delegate chores and foster shared ownership, then how can we expect a healthy future where the fediverse evolves and thrives? A grassroots standardization process must find ways to bring people together to further common interests.

Grassroots open standards

Section titled “Grassroots open standards”

Social experience design focuses on the intersection between Sustainable FOSS - named SOSS in SX terms - the social web, and collaborative commons. The goal is to establish self-sustainable commons that participates in a commons based value economy, exchanging services that offer solutions that serve people’s needs. This goal combined with the need to be able to scale requires going back to open standards, and follow standards-based solution development practices.

SX introduces the term Grassroots open standard and the business domain of Grassroots standardization that involves both the bottom-up and top-down processes of standardization. Grassroots standards are open access, driven by input coming from commons participants that are part of a rich, inclusive ecosystem. Grassroots standards are as much designed as they are ‘grown’ organically in an analogy to Nature. They are gradually improved by evolution, and so too are the grassroots standardization processes.

“Isn’t ActivityPub a grassroots open standard, and the FEP Process a grassroots standardization process already?”

No. Because it isn’t commons based, not under control of and by the people, and sustainable at any one time. W3C ActivityPub isn’t a grassroots standard because it isn’t able to evolve, and it isn’t sustainable because implementations introduce ever more protocol decay. Tireless fediverse pillar @evan is trying to bring top-down change to that, by bringing people together at the W3C. The grassroots FEP Process is only part of the overall standardization process, and isn’t sustainable either. FEP’s were introduced by @pukkamustard and @cjs but existed on a self-hosted git forge that was often down or had expired certificates. It was doomed to languish and fail, so I took the initiative to take the FEP Process to Codeberg and sought volunteers to form a maintainer team. Though great team members participated over time, today only a single individual is dilligently doing the boring commons janitoring chores. Our lone hero and second fediverse pillar @silverpill, developer of Mitra. This in itself makes the FEP process not long-term sustainable right now.

The W3C, top-down, and the FEP Process, bottom-up. They complement each other and might theoretically form a complete grassroots standardization process when tuned to work well together. For a time when I was still facilitator at SocialHub I spent a lot of time to advocate the emergence of a 3-stage bottom-up standardization process, depicted below ..

1st stage is the decentralized ecosystem, where SocialHub is part of and only facilitates the FEP process, which is the 2nd stage. The FEP informs the W3C who cherry-pick both from the FEP and from the ecosystem. The ecosystem either participates in the FEP or the W3C or both. Only the W3C gives formal guidance. FEP and ecosystem have mixed informative/ formal practices.

While well-intended and following the right idea, in hindsight I was naive and the proposal has serious flaws and challenges that make it unsuitable to work well against the social dynamics we find in the chaotic grassroots collaboration environment of the fediverse developer ecosystem.

Challenges of standardization

Section titled “Challenges of standardization”

What are the major challenges to overcome?

First there is the commons participation challenge. Most people simply do not want to do the boring chores, the commons janitoring tasks that need to be done. Especially if they already “crossed the chasm” and are unlocked, able to code and focus on their own app with enough ActivityPub expertise under their belt. That is reality, it is only natural, a fact. People are motivated first of all based on self-interested motives. Commons janitoring is highly unthankful, under-appreciated, and mostly unseen work.

Fediverse wouldn’t be where it is today, without the major backing that the European Union has provided over the years, in the form of grant funding and supportive services. Instrumental were the Next Generation Internet funding programs of Horizon Europe, facilitated by the hard-working folks at NLnet and led by Michiel Leenaars as director and strategist. Well over 88 ActivityPub projects have found support during the years, which includes me in the role of ActivityPub community steward. But there is only so much that organizations such as NLnet can do to strategically steer technology direction, before they reach their ‘span of control’ and risk getting mired in operational practices. Falling in the ‘pragmatism trap’ in a similar way as the supported developer base does.

The problem with the type of funding is the mandate that is given by the EU, which favors the creation of technical artifacts in typical FOSS fashion, but does not include the software lifecycle activities that lead to adoption, maintenance, and long-term sustainability and viability of new technologies. I call it “breadcrumb funding” and in a way it is not much different than a much scaled-down variation of venture capital funding. Provide capital, and see what sticks around, becomes successful. It is not a bad method of funding either. On the contrary, it has helped many flourishing FOSS projects into existence, that are now long-term sustainable. But as the only form of funding, and with its limited scope focused on FOSS software production, it is entirely unsufficient to address overarching concerns that keep a healthy technology ecosystem together, let alone foster and evolve good open standards and enforce the standards compliance the open ecosystem must rely upon for basic interoperability.

The commons based open standards movement still faces a near total lack of adequate funding.

Luckily there is a shift of focus in the funding landscape, that pays more attention to the entire supply chain including more socio-technical and even socio-cultural activities that are just as important. After all, coding is social. At least it should be.

Then the next challenge, when there are proactive participants, there is the issue of governance or the lack thereof, and the power dynamics that are related to this. People in chaotic social impact movements are fiercely independent and autonomous. They are highly alert and critical where it comes to matters of who has authority on what. This is a good thing, part of the values and freedoms to hold dear, free agency and open technology access, and fostering of safe and inclusive online spaces. But it also makes governance at scale nearly impossible, a “herding of cats” with clashing opinions, ideologies and cultures.

In the case of dealing with Linked Data versus plain JSON, who has the authority to make a decision? Perhaps even break backwards-compatiblity? The reality in current fediverse is that no one can affect the standard, but everyone can affect the installed base by just opportunistically coding the required change. The lack of governance and inability to have a say, leads to people not caring about the open standards, and it is only logical they act in this way. “Just do it” is simply the only pragmatic choice. But that credo is more value-aligned with Silicon Valley than it is with fediverse culture.

Standardization risks recentralization and corporate capture of the open standards.

Decentralized architectures, distributed systems, and above all chaotic collaboration enviroments pose great challenges to facilitate healthy technological innovation. The complexities involved and the urge to bring order to chaos often lead to top-down governance structures to shape up, gaining authority and power that in turn trigger forces of recentralization.

A certain extent of centralization is always required, if only to have a “single source of truth” for the ActivityPub protocol specifications. On the fediverse there are roughly four places where centralization takes place ..

  1. In server instances that host apps and services governed by moderators and admins.
  2. At the application or service provider via their FOSS project or proprietary product offering.
  3. At the FEP process, where proactive developers try to gain consensus for the extensions they use.
  4. Finally at the W3C, facilitated by SocialCG, and in future perhaps by a full Work group.

The need to have points of centralization becomes problematic where real recentralization takes place. A server instance that grows too large, a dominant app platform that shapes the fediverse to its will, or standards bodies that are overly controlled by gatekeepers that represent special interest parties. Today there are already frictions that hamper streamlined standardization processes and the ecosystem as a whole. The W3C has a problem of authority, where it is perceived by the more autonomous or even anarchist participants in the fediverse as a too formal organization structured to primarily serve corporate interests. This is not an unfair assessment, as traditionally most open standards are driven by representatives of large businesses, oftentimes by employees at Big Tech companies. And W3C is shunned for that reason by these people.

The FEP process serves to bring balance here, allowing open access standardization from the bottom up, but it faces its own challenges. Here the main questions developers ask is “Why would I put the time and effort into creating and fostering a FEP document, especially while I am not even really blocked in my own FOSS project?”. The FEP contribution is seen as a gift that requires ‘sacrifice’ in time, money, and effort, giving only few benefits in return. There is often the intent to write a FEP, yet it never happens. This indicates a failure and improvement point for the standardization process.

Real challenges exist when it comes to app platforms andd server instances. Both pose existential risk to the decentralized fediverse, if recentralization goes rampant. The fediverse today is purely app-centric, and has the widely known issue of Mastodon being overly dominant, such that it shaped fediverse in its own image. Here SX does NOT lay blame with Mastodon, contrary to many critical fedizens. After all, as earlier explained, you can expect nothing other than software artifacts with software freedoms from a FOSS project, an autonomous ecosystem participant. If there is blame it is that the ActivityPub protocol isn’t robust enough to guarantee decent interoperability levels so that this isn’t a problem. The fault is once again with the standardization process, which should be strong enough to steer the technology landscape as a whole. This is also the case for server instances becoming overly large. What if mastodon.social became the centralized home of 4 billion fedizens, running on Mastodon data centers? It is the protocol design itself that determines the attractiveness for Mastodon or any other party to go that direction. And of course very importantly the culture and social norms fostered on the fediverse shouldn’t allow this to happen.

Corporate takeover pending

Section titled “Corporate takeover pending”

Here comes the biggest challenge then. With all the flaws and frictions, the misconceptions and the holes in the specs, and the autonomous nature of the ecosystem we can conclude ..

The ActivityPub open standard isn’t commons based and corporate takeover is guaranteed when mass adoption comes.

In 2023 Meta released Threads with a basic level of ActivityPub support and built on top of the Instagram technology stack. Though many people think Threads is another failed product introduction by Mark Zuckerberg, I consider it a very smart strategic move. To Meta the launch of Threads constituted a neat and cheap experiment that was highly successful. Just a handful of time and resources and now Meta is ready as a strategic spider in our social web, to either snuff out broad adoption should it come, or become the dominant market leader if they decide to take a front seat. If that happens they will not go with a half-baked unprofessional standardization process, but will launch their own full-blown developer portals just like they did before with React and GraphQL. The rise of AI significantly increases the risk of either an extinction or embrace by undesirable and exploitative commercial parties. It has become much easier for any person to launch their vibe-coded fediverse apps, and by doing so demonstrate the areas where there is real market value, attracting corporate entities.

The corporate social web from a pure technical perspective will be a real blessing to developers, who are finally fully unlocked to immediately focus on solution development. The fediverse developer ecosystem will balloon with people who do not know anything about FOSS culture and values, and the passion that drove the early pioneers to pursue a decentralized social web. For the early adopters and fedizens, but also for our society as a whole there will be a HUGE missed opportunity, and a possible total failure if the outcome of all the work is that Big Tech is now even closer to our skin, e.g. using roaming AI personal agents on decentralized technologies. And continue to depersonalize and erode the social fabric of society in their usual disruptive ways, that undermine our hard-won freedoms and democracy.

Unfortunately my opinion that fediverse isn’t ready for prime time yet is controversial. There is something of a chism in the ecosystem between BigFediverse and small fedi proponents. Where a sizable group of people DO think that fediverse is ready for the masses right now. Or that given the urgency to have alternatives to Big Tech social media platforms, applying growth-hacking tactics is the right thing to do. Meanwhile another group of people favors the small web approach. Small-world networks, inter-community and friend-of-a-friend like cozy relationship networks. Which is a more innovative social web in my opinion, that follows a more interesting and future-proof shared (technology) vision. Ideally a good grassroots standardization process provides a place for both of these groups to satisfy their needs, while staving off the risk of unwanted corporate capture.

Dare to dream, dare to play

Section titled “Dare to dream, dare to play”

The two pillars of the fediverse, @silverpill and @evan, do their stinking best to lure people into proactive participation and make them volunteer their precious time. After a decade of doing community work, and facilitation of various communities, doing technology evangelism and “weaving in public” I know as no other the ups and downs, and the deep frustrations that can come with this commons janitoring work. Oftentimes it feels like pulling a dead horse, and that despite all efforts there is hardly any progress. Commons janitors also often get criticised by bystanders on their volunteer duties, and the decisions they make. On the other hand, when things do turn out well, and unexpected collaborative arrangements shape up, it can be very elating, satisfactory, and rewarding too. Worth the time, money, and loss of income. Worthy of our passion. Aligned with our dreams.

I assume that both @silverpill and @evan aren’t in it only for the pure love of things and doing their janitoring as pure hobby. That there are more hedonic drivers and self-interested motives at play that drives them to foster hedonic peer production in the commons. They each pursue larger personal goals.

The same is true for me. I came to the fediverse in 2018 and became facilitator of SocialHub for a good number of years, because I required a healthy and vibrant ActivityPub-based ecosystem that didn’t yet exist, and still doesn’t exist to this day. At least not on the original promise and power of the technology. My interest area involves Residential social networking, where the social network induces people in towns, cities, and rural areas, to engage offline and contribute to the local economy and strengtening of social cohesion between residents. In this type of social network the residents do not only create content, but are able to add their dynamic apps and services with relative ease, to enrich the overall social experience on their residential networks.

I feel the fediverse is at an inflection point. The fediverse-we-have has a future, and perhaps a bright one too. Personally I love what Mastodon offers me, and I get value from my microblogging. Yet it is not, no longer, the fediverse I became active for in the commons, doing my own commons janitoring duties. Like many others before me - including most of the innovators looking for more vibrant cocreation spaces, and many protocol experts involved from the very start - I may soon seek greener pastures. Continue the quest and look for more promising social networking technologies that align better with my aspirations for “The Decentralizated Web”. Pursue my dreams elsewhere. Yet there still exists big opportunity to turn the ship and correct course ..

Fediverse is at an inflection point where the ActivityPub API can be the Grassroots standard that puts it back on track.

The title of this section refers to two important hedonic drivers that help entice people to become proactive participants in any technology ecosystem. A good grassroots open standard and standardization process can incite these in people and attract them to become active. A robust protocol helps people think of all the exciting things to build on top of it, and dare to dream. A healthy commons based process encourages people to play together with others and imagine what is possible, so that it can be realized. Going from dreams to their realization is what SX offers to practitioners in the personal level of the Pyramid of perspective.

Grassroots open standards are emergent by nature, they evolve and aggregate value in two cent increments.

I am merely a generalist, and a dreamer at that. I am neither a protocol expert nor am I a ten times developer. I have many ideas on how grassroots standardization processes may function. But ideas are cheap. Grassroots standards grow organically where ideas take hold, and this involves many people acting together, cocreating things.

Decentralized specifications

Section titled “Decentralized specifications”

Coding is Social. That is the premise of Social coding commons. Everything in IT revolves about people, and how together they produce tech artifacts, software that serves people’s needs. Isn’t it ironic that for the ActivityPub fediverse - which promises social networking that is “by the people, and for the people” - a deeply social process such as the interaction design between the solutions that we build to serve society, we never really thought about decentralizing that process using our own cocreated social web technologies?

What if the ActivityPub grassroots open standard were entirely decentralized, equally owned by everyone, every fedizen and fediverse developer? What if the process of evolving the open access specifications were native to the social web? In what ways might we achieve that, and what would be the possibilities and opportunities, the potential that that would have? What if the standards body weren’t a hyperformal organization, but the collaborative commons itself? A sovereign, self-governed grassroots open standard in a self-organizing grassroots commons? Let’s explore these ideas further.

Specification as code

Section titled “Specification as code”

Protosocial protocol is an initiative to create an ActivityPub extension that goes back to first principles outlined in the W3C open standard. It is a SOSS initiative on my hobby track for the time being, as I have no income at the moment and neither do I have savings. Protosocial brings a service-oriented overlay network to the social graph of actors, thus has the opportunity to plug misconceptions and holes that the open standards do not address. Protosocial social networks constitute of a social web of Services where Actors can be introspected for the services they offer.

Sticky note that represents the Protosocial SX solution and reads "Develop fediverse services with ease".

This post is not about Protosocial, but mentioning it here for how it intends to encapsulate the design of a service with the service itself. While the introspection mechanism is initially but very basic, the idea is that eventually a deployed service bundle will contain its full design specifications, docs, and perhaps even the codebase itself. To be either retrieved or machine-introspected at runtime via service discovery and service delivery (handshake and invocation).

Objectives are that ..

  1. Think. Services are self-contained without dependency on remote owners.
  2. Act. The design specification of a service becomes truly decentralized itself.
  3. Feel. Service integrators are relieved from plumbing to focus on their solution.

There is a huge body of work in IT around the subjects of service delivery, discovery, introspection, composition, orchestration, and choreography. Numerous approaches and mechanisms exist to take inspiration from and adopt. Weigh the pros and cons and a find transition path from simple to more intricate and automated ways to discover and invoke service specifications.

A basic but well-thought out introspection mechanism is offered by XMPP protocol in their XEP-0030 Service discovery document, and a number of related specs.

Specification-as-code is a form of Living documentation, which constitutes an application domain in itself that is candidate to get social web support. A well-known example of living documentation is OpenAPI, but more appropriate for the fediverse would be AsyncAPI that can be extended to be a good fit to describe ActivityPub services. Protosocial as an overlay protocol can dictate the presence of introspection points, where AsyncAPI, JSON Schemas, or LinkML documents are available on its Actor API’s. Taking a standards-based approach, adopt more standards and unlock the tool ecosystems they support. Such as the living documentation environment EventCatalog to name but one ..

Screenshot of the EventCatalog user interface, copied from the project website.

Wouldn’t it be delightful if you could take any actor endpoint URL, load it in your tool and be directly in the service delivery cockpit of your social web integration designer? Design or adjust service specifications with UI guidance, generate code, bootstrap integration projects.

Specification hubs

Section titled “Specification hubs”

Where the haphazard proliferation of protocol flavors has all the characteristics of a NPM-like dependency hell in the making, mechanisms such as actor introspection, specification-as-code, and fully self-contained services are more analogous to an environment where a git-like distributed version and revision control can be modeled.

The core specs of ActivityPub still need the most formality and rigour, careful design to adhere to the robustness principle. They need a proper source of truth, and the best upstream repository for that is still likely the W3C and other well-established standards bodies.

When it comes to extensions to the core protocol, we can discern different categories that each require different evolution processes, governance models, and levels of formality ..

  • Protocol capabilities that are normative or highly recommmended.
  • Protocol capabilities that offer functionality that is optional.
  • Protocol bridge designs to other social web and communication protocols.
  • Generic business and application domains that facilitate app and service solution design.
  • Custom app or service specific extensions offered by single-party providers.
  • Experimental extensions in all of the above categories.

With specifications of the federation protocol now turned into regular content that is a native part of the federated network, i.e. specification-as-content, organization of the editorial processes around them becomes box-standard fediverse solution design. Organizing the social graphs to bring participants together and enforce the desired level of governance becomes inter-community social networking very similar to what existing fedi apps like Lemmy and especially Bonfire already do. Many parts of the grassroots standardization process can be built from generic building blocks that serve various business and application domains, which can find much broader reuse, such as simple federated document synchronisation.

Where multiple parties want to offer integrated solutions in a particular area, they no longer need to organize from scratch, and maintain their custom toolstacks, techstacks, and communication channels. They may spin up Specification hubs, fediverse server instances that are configured to ‘hold their hands’ in the specification stream, and filter out what they need for their developer portal. They can benefit from everything that is already natively supported on the social web, bootstrap into existing ecosystems.

The protocol might support the notion of Profiles, that allow to precisely specify the composition of specification parts and their relationships. There may be an ActivityPub_v1 or even Mastodon profile that defines a backwards-compatible protocol configuration in continued support for fediverse-we-have. When all this is done well, it will create an impetus to adopt the new ways of social networking. The obvious path, that simply yields most benefits and opportunity, and may even persuade inwards focused post-facto interoperability leaders to heed the broader ecosystem and become more active participants beyond their own app platforms. Persuaded by ecosystem attractiveness.

Fediverse evolution process

Section titled “Fediverse evolution process”

I concluded above that the current FEP process is unsustainable. If the current volunteer(s) burn out and leave, and no others step to the plate, then the FEP will likely lose relevance quickly and eventually be abandoned altogether. If the fediverse sees corporate capture, then the FEP will be replaced with something deemed more professional in the eyes of business people.

With regards to the funding landscape there is a big shift coming, that represents a similar shift in the world of business and government: An attention and focus shift on the quality of the overall software supply lines. A large EU institution simply will not adopt a single-person FOSS project and will demand a whole range of regulation compliance that guarantee service quality and availability. The current NLnet funding programs that supported so many FOSS projects come to an end in Summer 2026. They are to be replaced by different NGI grant programs, that raised fierce discussions and controversy in FOSS circles by how they supposedly will make it harder for small FOSS projects to be eligible for funding in the future.

Diagram depicting the Free software development lifecycle, which consists of 5 stages. Consecutively these are Inception, Ideation, Realization, Delivery, and Dispersal. The stages are labeled with the corresponding hedonic incitements of think, act, feel, play, dream, and be. Overarching all stages is Evolution of the solution throughout the entire lifecycle. The process of "service delivery" covers all 5 stages, while "value creation" ends in stage 4 when Dispersal of the value starts. Solution design covers the first 3 stages up to Delivery. Software development happens mostly in Ideation and Realization stages.

Social experience design, being an emergent and evolutionary methodology, thus evolved to anticipate these changes. The FSDL which first stood only for “Free software development lifecycle” to cover the whole life of a SOSS initiative (i.e. sustainable FOSS) and its relationship to the commons, now has an overloaded meaning of the acronym depending on context. At the inter-personal relationship level of the Pyramid of perspective i.e. where the social graph and service exchange between autonomous actors is modeled, the acronym stands for “Fediverse solution delivery lifecycle”. At the top level of the pyramid, at the largest scale, SX focuses on the Social supply chains and the ability to offer scalable socio-cultural solutions that are strategically designed to have positive societal impact, leave societal imprint in the form of durable change that in turn make transitions possible that solve wicked problems. But that is for the future. SX works at any scale, and we must start small.

The FEP process as it stands today, is but a small part of a larger supply chain. And yet a tremendous amount of time and effort went into its organization to a sufficient level of usefulness, and to see a good measure of adoption across the fediverse developer ecosystem. Driven by great commons contributors like @silverpill, @helge, @trwnh, @stevebate, @weex, and many others, a large list of FEP documents has been compiled and curated, available on stable URL’s, and published on a purpose-built portal website that is being further improved right now. But it is all custom development and organization in a different techstack and toolstack than what is commonly used by ActivityPub developers in their federation projects. Furthermore the website is already being forked at random disconnected places, not upstreamed, and risks seeing forks turn into hard forks that lead to further fragmentation of the ecosystem.

Wouldn’t it be incredibly exciting if every ActivityPub developer could join an ambitious innovation adventure and help develop the social supply chain to introduce Grassroots standards as a natively supported social web capability? And deliver Grassroots standardization as a socio-cultural social network solution that is exactly tailored to the grassroots nature of our fediverse culture and environment?

Such an undertaking would constitute a triple win in SX terms. Strategically evolving a win-win situation with maximised synergy. Learn the tech by building the tools while applying them to own solution design to reach personal goals sooner, and in collaboration with others who do the same. Enter into a cocreative arrangement, where actual service exchange is the basis for the collaboration, and the more proactive one is, the more benefits and rewards are the result. Which makes volunteering to participate increasingly more attractive in a kind of linear growth to ecosystem expansion. Among the rewards will be increasing opportunity to earn sustainable income from FOSS and social benefit activities.

Sustainable commons based evolution

Section titled “Sustainable commons based evolution”

A truly commons based fedi is possible. Commons based under SX means that the commons is in full control. That it is self-sustainable and also able to protect itself against malign influences and bad actors. Resilient against forces of enshittification.

I want to briefly return to corporate capture and hostile takeover risks that loom for the fediverse-we-have, to be triggered by popular uptake and adoption. And note that if any of my brainstormed showerthoughts above would take real shape, it would lend significant resilience to malign corporate influences. Here is where a chaordic commons has the potential to be stronger even than their exploitative commercial rivals.

A sustainable and activated chaordic commons is able to outcompete ANY shallow commercial venture.

Let’s see what is gained by adopting Grassroots standardization ..

  1. Sovereignty. There are no gatekeepers. No one owns the open standard nor the standardization process.
  2. Autonomy. Specifications are decentralised, and the protocol is modular and composable from constituent parts.
  3. Freedom. Actors and services are licensed on the wire, machine-readable, and may even bundle the full codebase.
  4. Controlled access. Access and participation follows regular moderation, security and privacy capabilities fediverse offers.
  5. Versatility. Interest groups can foster and care for specialized social web areas and offer tailored experiences.
  6. Cohesion. The chaordic organization of the standards movement is the friends-of-a-friends, inter-community social graph.
  7. Solution focus. No distraction from tech details and myopia for impact and externalities, focus on satisfying people’s needs.
  8. Shared vision. Using social web in scenario’s that demonstrate its true power, not decentralized clones of existing social media.
  9. Supply chain support. Increased focus on the end-to-end lifecycle of solution delivery and how they comply to people’s needs.
  10. Social experience. Provide a social web that is diverse, fun, exciting, and has inherent creative power that can affect change.

The greatest thing about following the emergent evolutionary development approach that SX offers, is that it has the potential at any scale to turn Conway’s Law in our own favor. In a chaordic grassroots environment that is shaped and coordinated to bundle and direct people power, seeing people activitated for prolonged times in collaborative arrangements that are more beneficial and rewarding than going it alone. Then social dynamics become such that they simply do not provide a foothold and furtile ground for those who exercise undesirable hypercapitalist - top-down, unorganic, sterile - business practices. The fitness formula of the commons is not “survival of the fittest” anymore and does not intrinsically reward foul play and bending of the rules. Instead the bad actor stands to lose and push themself out of the picture into irrelevancy if they only extract value and give nothing of value in return.

Responsible custodianship services

Section titled “Responsible custodianship services”

Michiel Leenaars gave a keynote speech at the FOSDEM 2026 conference, titled “FOSS in times of war, scarcity and (adversarial) AI” that I encourage anyone passionate for the commons to watch. It tells the tale of how we must be more like Sun Tzu and “Know thy enemy”, be smart and clever about how and when to engage them. The best war is the one that never needed to be waged, because of good preparation and taking precautions and protective measures.

Key lacking element for Grassroots open standards to still address is Sustainability in FOSS based technology ecosystems.

Since SX is a sustainability-first methodology, that is a great dealbreaker that complicates the transition of the fediverse into healthy territories. However, in the commons everything we need to become self-sustainable is already available. It is only loose and scattered, fragmented, not scaleable, which is characteristic for any chaotic grassroots environment. This is where deliberate evolution of chaordic organization comes to its full potential. SX solutions evolve from a sticky note. The only thing that is needed as starting point and assurance for sustainable evolution is responsible custodianship that is firmly anchored and rooted in the commons.

Institutions like Commons convervancy can be native social web custodianship and SOSS sustainability anchor points.

The landscape of organizations that offer support for FOSS and social impact movement is as chaotic and fragmented as the movements they serve, with support services that regularly overlap, duplicating or excluding each other, and have complex eligibility requirements. Creating a very hard to navigate terrain for the average FOSS software developer, as they get exposed to more and more different areas of expertise that their FSDL evolution stage requires, as their projects scale and find uptake and popular adoption and use. The average FOSS developer does not recognize well the changing needs their projects require, and often even don’t consider themself as a stakeholder with their focus on ‘users’. Finding proper support in timely fashion is like doing quests in a MMORPG and find mystic shrines with treasure. Sustainability is by no means a strategic progress to be monitored like the stats of your role-playing characters. All this makes the failure rate of promising initiative unnecessarily high.

Quotation attributes to Sun Tzu that reads "Victory comes from finding opportunities in problems". Sourced by AZ Quotes

As mentioned there is increased attention for this challenge, even wicked problem, of making FOSS projects more sustainable and FOSS work more beneficial for society, address the negative externalities we now overlook. There is a huge potential for organizations to offer FSDL related support services to commons participants and the broader public, in ways that combine efforts so that collaboratively a self-sustainable value economy may emerge in the commons.

Across full breadth and range of the FSDL there is great opportunity to offer integrated social web support services.

Michiel Leenaars early on in the role of strategic director at NLnet recognized the importance of addressing the entire FSDL and made the NLnet-offered grant programs as easy-access and low-barrier as possible, providing additional services as part of the program, founded satellite and complementary institutions, and forged a huge strategic partnership network. Today it serves as inspiration and exemplar for other social impact organizations to bring a more holistic approach through their service offerings.

The Commons Conservancy is a Dutch ANBI non-profit, a public benefit organisation that focuses on establishment of a technology commons, and has the following Mission ..

That is a fabulous alignment with the ideas and concepts presented in this brainstorm session that matches closely nature as well as needs for fostering Grassroots open standards as well as compliance to them, and also to take custodianship of the SX methodology and practices as they emerge and evolve, across the entire spectrum of the FSDL.

I made an appeal and proposal to Michiel Leenaars in his role as chairperson of Commons conservancy, that is based on this close alignment, and which I hope he will take to heart and closely consider for its merits. For commons conservancy and its strategic affiliation network it provides opportunity to adopt bottom-up grassroots organization best practices and innovations, and combine that with their existing strategic governance structures that are organized in more traditional top-down fashion. Like all known forms of organizations under hypercapitalism, these do not scale beyond a certain size, and have to be upheld against forces of Nature artificially, fed by continious extraneous energy and investment of money. If my proposal is received positively, then a SX solution sticky note will be dropped onto the table and a pragmatic start can be made to remodel the FEP into the Fediverse evolution process to gradually evolve the concept of Grassroots open standards on the social web. And yet another triple win can be cultivated.

Fediverse tomorrow

Section titled “Fediverse tomorrow”

In the past I have been frustrated, disappointed, disillusioned about the turn of events and direction of the fediverse, and the lack of progress and true innovation. But I managed to overcome that, and learned something truly beautiful. Namely that I was also deeply under the yoke of hypercapitalism, full of dogma and fed with newspeak my whole life, even while fighting against rampant hypercapitalism with my community efforts. I was trying to steer forces that don’t allow themself to be steered. And I came to the insight how these forces were nothing less than those driven by the Laws of Nature themself, wild and emergent. That only when we truly understand the complex social dynamics in a grassroots commons, do we have any chance to truly deliver online social networks that support them properly. And that, at societal scale, this constitutes the only way to get rid of the current system and transition to a better and sustainable world. The only way to solve the truly big wicked problems of our time. We must beat Conway’s Law and think out of the box. Follow where Bret Victor, imaginative thinker, spends his life pointing out the path to follow.

All these thoughts wirl through my head, as I am writing this article. I am a dreamer, and these are all but dreams. They are part of my imagination of how the Future of social networking may be shaped in practice. What direction do your dreams and fantasies, and perhaps concrete plans, move towards? I encourage all fedizens to reimagine social together, as a collective that is able to pursue a bright vision in utterly gloomy times given the sad state of our modern world, and make real progress towards its realization. In dark times it takes guts to dream, and share them with others. I dare you to reimagine social. To dream too. If only just for you. It is always the two cents that matter, and that you spend them well. They accrue over time to something more than their intrinsic value.

Joyful creation

Section titled “Joyful creation”

I have Grand Dreams, yes. It is good to have those. But I also have plenty of small and humble, pragmatic ones that I pursue. My needs in life are but humble too. I crave stable income and a pension, some vacation money, to lead a simple life with friends and family and have nice things to do. I have always sought work that was also my hobby. That turned me into the generalist I am today. Because dreams change, and that is okay: You can just follow them if you dare. No pressure though. Timelessness is part of the Mindfulness core principle of SX. Things come as they come in life. What I was after most, was to experience the “Joy of creation”, to be creative and imaginative in my crafts. What dreams do you have, and are you moving towards them ?

Today, out of money, savings, and income - having deliberately exposed myself to the inherent unsustainability of the chaotic commons to learn from first-hand experience, and now nearing the end of a typical “FOSS burn cycle” that my privilege allowed - I am uncovering an entire new field of IT with Social experience design. Unexplored terrain where Adventure can be found. And I shaped a “Dream job” for myself, where I hope to find a future. To be a Social experience designer and a Dreamer. Two different hats to swap when doing my work and daily routine, and more to come if it is up to me. What are your dream jobs in life ?

A social experience designer is a concept and solution developer that helps realize positive societal impact.

The fun part is that, with SX of near unbounded scope and focus on all of society, anyone else can be a Social experience designer too. It doesn’t take a course, or a training, a certificate of practice. Dream jobs are emergent too, and they evolve. Mastering one comes with time and practice, following dreams, and above all.. with social experience. Any SX solution is said to exist when you can write it on a sticky note. Are you perhaps a Social experience designer too ?

Just consider all that. And you can experience the Joy of creation every day. It merely requires progress, two cents of value at a time.

“Joyful creation” is the name of a vision and formula that SX evolves solutions for, in the form of SOSS initiatives that help innovate the social web. The name was inspired by Dan North’s “Joyful coding” mentioned in the CUPID properties that are in turn a reaction to the more rigid and formal SOLID principles many people follow for software design. CUPID is more aligned with how a grassroots commons cocreates.

For the fediverse Joyful creation means that the solutions, all the apps and services that are available on the social network, offer full support for the sustainable evolution of the the network itself. An example of that is the NLnet supported ActivityPub protocol extension project ForgeFed. It was led thus far by Pere Lev, who is in search of people who want to carry the torch from here, towards broad standards adoption. The Forgejo code forge project, that Codeberg runs on, has a forge federation satellite project, that intends to implement ForgeFed and connect all the dispersed forgejo forges and their repositories together, on the social graph of the fediverse. Following the vision of Joyful creation, and applying SX, would see this protocol specification mature into an grassroots open standard that faces up the stack and serve the entire “Software development” business domain on the social web. Instead of narrowly focusing down the stack to facilitate the minimum common denominator of existing code forge software platforms, as it does today in its current draft. That repositioning would turn nearly all software development tools into candidates to become federated. Most online applications are after all social in nature, and Coding is Social. “Commons based software development” may constitute a radical next-gen social networking innovation that goes well beyond stargazing a repo.

Peopleverse ?

Section titled “Peopleverse ?”

To top off this lengthy blog post, let’s close with another #ThoughtProvoker and echo a tired Big Tech moloch with “Where would you have wanted to be today?” and ponder the shared (technology) vision we might embrace collectively. One that leads us to the Future of social networking. Unleash the Bret Victor in you and dare to think out of the box.

How do you #ReimagineSocial ?
Do you dare to dream? Then Dream.
Do you dare to play? Then Play.
Can you imagine a peopleverse ?
Then let The journey begin.

If all goes well and I manage to sustain myself somehow to stay in the commons, I plan to follow up this blog with much more concrete and in-depth explorations of the various design concepts and how they may take shape in solution development and delivery. I will keep you posted :)

Additional information

Section titled “Additional information”

Discuss your thoughts with me on the fediverse, on our social coding forum, or in the Social experience design channel.

IETF Best practices

Section titled “IETF Best practices”

At the IETF a number of great documents are available with best-practices and guidance for robust protocol design:

Delightful commons

Section titled “Delightful commons”

Be sure to check out the fedi-related curated lists kept by the Delightful commons initiative, that is part of Social coding commons:

Protocol design opportunity

Section titled “Protocol design opportunity”

Throw your weight behind development of the ActivityPub API and help make a positive course correction of our fediverse ecosystem. Just like these initiatives already do.

In relation to this article, see also the “Avoid misconceptions” and “Protocol design” issues I created in the ActivityPub API task force repository, part of the W3C Social Web Incubator Community Group (SocialCG).

NLnet funded ActivityPub projects

Section titled “NLnet funded ActivityPub projects”

Through the various funding programs of Horizon Europe’s Next Generation Internet initiative, the following 88 projects received NLnet support in the past:

#Seppo!
/kbin
ActivityPods
ActivityPods 3.0
ActivityPub community steward
ActivityPub Quote Posts
Bonfire OpenScience
ArtistHub
Betula
Bonfire federated groups
Bonfire Framework
Bonfire Search & Discovery
Castopod
Castopod Mobile
Castopod Plugins
COCOLIGHT
Discourse ActivityPub
Dokieli
Dokieli Collaborative
Drupal ActivityPub integration
Drupal ActivityPub module usability enhancements
Drupal ActivityPub Social Recipe
Empowering Mobilizon
EU Voice-Video case study
Event Federation Plugin for Wordpress
FairSync
Federated software forges with Gitea
Federating Mirlo
FediMod FIRES
Fediverse Test Framework
Fediverse Test Suite
fediverse.space
Fediverser
Flarum
flohmarkt
ForgeFed
ForgeFed Frontend
ForgeFlux
Funkwhale
Funkwhale Federation
Gancio
GNU Social
GoActivityPub
GoToSocial
GoToSocial performance & connectivity
Hubzilla
Hubzilla performance improvements
Interoperability of Events in the Fediverse
Inventaire Self-hosted
Kazarma
lemmur
Lemmy
Lemmy Federation
Lemmy private communities
Lemmy Scale
Loops
Manyfold
Manyfold Printing, Customization and Versioning
Mastodon groups, filtering, moderation
Mastodon for institutions
Misskey
Mobilizon
Mobilizon UX
Nextcloud
NextGraph
NextGraph Framework
NodeBB
NodeBB context discovery
Omnon
openEngiadina
Owncast
Peertube
Peertube Remote Transcoding
Peertube plugin livechat
Peertube Desktop
PixelDroid
PixelDroid Media editor
Pixelfed
Pixelfed Live
Plaudit
Pleroma
Podlibre
Popularizing Peertube
Solid-ActivityPub Interop
Tusky
WordPress ActivityPub
XMPP-ActivityPub gateway
XWiki ActivityPub