Paradigm shift to the Prosocial web
As mentioned in Grassroots fediverse evolution the ActivityPub API is one of the most promising areas of innovation for the fediverse. This standardization effort around the client-to-server specification profile of the W3C ActivityPub recommendation allows a further decoupling of client and server software. A versatile social web of independent clients that interact with many interoperable apps and services comes within reach, offering opportunity to break the dominant role of platforms on the fediverse and reduce its app-centric nature. Unfortunately there is no real consensus on what the ActivityPub API should offer, and there is little coordination between stakeholders, in true grassroots fashion. This article investigates what is happening in the developer ecosystem.
Contents
Section titled “Contents”- Fediverse needs a paradigm shift
- Shift to the sociosphere
- Fediverse solution development
- Major social challenges
- State of the ActivityPub API
- Raising the stakes
Fediverse needs a paradigm shift
Section titled “Fediverse needs a paradigm shift”For Social experience design (SX) I use the simple notion of a sociosphere and a technosphere, where the latter should support and help satisfy the needs in the former. An observation is that in modern society, generally speaking, we give too much credence to the technosphere. We take the idea that innovation equates to societal progress as a given, to which we must subsequently adapt ourselves. We tend to turn things around, where “digital transformation” suddenly means how humans must adapt their lives to new technology that comes to disrupt it. And not the other way round.
Fediverse has evolved purely as a technosphere. Based on W3C ActivityPub the fediverse comprises an open technology landscape to explore, where software developers in a small developer ecosystem launch federated apps for their users. FOSS culture is the sole driver of fediverse technological evolution. Governance and authority in this technosphere fediverse is grassroots and splintered between countless independent parties. Random emergence is the evolution mechanism. Whichever FOSS app platform gains dominance in a particular functional area, becomes the driver of post-facto interoperability. In this way, driven by Mastodon’s application development, Microblogging has become the most prominent application domain of the fediverse.
Fediverse today is a technosphere, decentralized on the basis of app platforms, evolution determined by popular app demand.
This is not much different than Web 2.0 we have today. Laissez-faire product development of independent application platforms is a very bad driver for sustainable organic growth of the fediverse social network, and makes it really hard to introduce prosocial solutions that help foster healthy online culture across the network. Furthermore there are real risks for recentralization and corporate capture.
Using SX, when considering the technosphere, “fediverse” is just a category word similar to how we refer to “web” and “internet”, encompassing the technology stack and installed base of software and servers.
Shift to the sociosphere
Section titled “Shift to the sociosphere”Social networking is any direct and indirect human interaction between people. This is the full scope of the sociosphere, where people and their mutual needs are directly considered. In the sociosphere SX involves solution development of prosocial solutions where the fediverse is considered from a more socio-cultural perspective.
“To put it simply: Business gives us endless Talk for free, AI gives us endless Code for free, but the Source, the real reason behind any of it, can only come from us, Humans.”
– “Talk is Cheap. Code is Cheap. Show me the Source” by Zororg
The focus is on participants on the network and their social interactions, both online and offline. This perspective includes all stakeholders, considers their motivations and the needs they want to satisfy. These determine the social networking requirements of a SX solution, and drive evolution in the technosphere. Practicing SX solution development is advantageous for individual FOSS projects to become more sustainable, but becomes most impactful when applied at scale across a commons. A paradigm shift is possible that realigns fediverse with the sociosphere.
Fediverse as a sociosphere consists of interacting online services consumed by people via autonomous clients that offer solutions for their needs.
Service-orientation, creating a “Fediverse of Apps & Services”, breaks with the app-centric paradigm. Instead of driven by individual FOSS projects and their app platforms, the fediverse evolves purely on the basis of solution development. A fediverse solution is an extension built on top of the ActivityPub protocol, that introduces a particular service to the larger fediverse social network. Solutions in this paradigm must be based on a mature ActivityPub protocol specification and a robustly defined extension mechanism, both of which are not yet available today. The ActivityPub API initiative can be the enabler of an important paradigm shift, and a bright future for the fediverse.
Fediverse solution development
Section titled “Fediverse solution development”In the SWICG ActivityPub API issue tracker @thisismissem@hachyderm.io made a comparison with the ATProto architecture, and drew a diagram depicting the fediverse we have today, where app-specific clients of the social network require the use of proprietary platform API’s to interface with the ActivityPub social graph.
In the current app-centric fediverse, a “user” - because that is how people / fedizens are called today - should worry if their Mastodon post is displaying correctly to a GoToSocial or Hubzilla user. They are entirely dependent on the goodwill of the FOSS development team that created the app they chose to access the fediverse with. Users can’t state their needs with regards to the social network as a whole, currently. Instead they are expected to suggest an application feature in the issue tracker of their chosen app, and hope that it will be honored. Fediverse application developers must develop their app against the features of other apps and continuously fix breakages based on their release cycles, in an anti-pattern called “Whack-a-mole programming and maintenance”. The fediverse as a whole evolves on the basis of the “Big ball of mud” anti-pattern, creating a software system that “lacks any perceivable architecture”, according to the Wikipedia description.
Below is the scope of the ActivityPub API initiative. This grassroots standardization effort provides great opportunity to make Fediverse solution development the key driver of fediverse evolution. One that is focused on emergence of a Prosocial web.
- Beneficial to all parties and consistent with community laws and mores.
- Contributing to a beneficial outcome by negotiation, problem solving, problem analysis, clarification, or respectful behaviors.
The ActivityPub network protocol makes decentralized social network communication possible, defines the Transport Layer. Meanwhile solutions are modeled by the communication itself, in the Data Layer, as ActivityPub extensions. A clear distinction between what the protocol implementation handles and where solution development begins, is crucial for a healthy evolution of the fediverse.
The ActivityPub API decouples clients from servers, and defines a generic Social API for fediverse solution development. An ActivityPub API conformant implementation provides C2S clients remote access via the Social API to the social graph and the social networking services the fediverse offers. The conceptual architecture gains more similarities with how ATProto works, in particular their Personal Data Service (PDS), something also observed by @kopper@not-brain.d.on-t.work for their now archived C2S server project.
The diagram at the top of this article shows how a Person actor interacts directly with social networking services, and is no longer tied to the app platform. These social networking services, rather than being the result of app development, constitute a shared consensus on how to model particular needs of the social network that stakeholders have.
In the client-to-solution approach stated needs are the driver of requirements. For a Journalist stakeholder their need might be “As a journalist I need my publications to timely reach their intended audience”. And that statement leads to a further breakdown into what they mean with “timely” and “intended audience”, and how they want to reach their audience. These requirements relate in general more to business domains than to application domains, and are independent of any particular app. Stakeholder needs are actual needs people have, contrary to application needs which are often based on past design decisions or to tackle unforeseen side effects. A prosocial web that evolves by deliberate solution development will be much richer and more versatile. The paradigm shift will transform how we talk about the social network, where it is no longer tech talk that prevails, but the language of the stakeholders is used instead. Design for interoperability will not be a second-hand concern. Instead interoperability will be the norm, native to any solution, while platforms and apps may still decide to offer app-specific features to discern themselves from others.
Major social challenges
Section titled “Major social challenges”Having solution development be the driving evolutionary force for the fediverse, instead of app development, constitutes a major paradigm shift. Introducing this shift also comes with major social challenges. These are basically the same I formulated four years ago. The ActivityPub fediverse is unique in how a grassroots movement managed to forge an open standard and create a popular technology ecosystem. But it is not unique in its social dynamics, where fiercely independent people struggle to coordinate in chaotic collaborative arrangements, each with their own ambitions, aspirations, and expectations that drive their involvement and contributions. Lacking an overall vision of what the fediverse should be and what it should offer, and lacking a set of common values to apply to its evolution.
The discussions around the future of the fediverse are all-technical in nature, completely lacking in socio-cultural depth.
In theory an all-volunteer effort could organize ActivityPub as a Grassroots open standard, but in practice this requires “stayers” who dedicate themselves nearly full-time. It is a tragedy of the commons that the current FOSS ecosystem is hardly sustainable, lacking funding even for pure technological development, and being completely underfunded when it comes to social development. As a result the commons remains splintered and fragmented, dedicated only to technological progress, evolving ecosystems in de-facto, haphazard fashion. Its only resilience is the chaos from which it emerges, which slows down innovation, and keeps unwanted corporate actors at bay.
In the past I advocated hard for a 3-stage bottom-up standardization process. And in theory a well-formulated staged process defined by the SWICG drives the technosphere of the fediverse ecosystem today. In practice it does not work that way, and the SWICG is just another group of developers in a fragmented ecosystem. Buy-in cannot be defined top-down, but must be earned by social engagement. I gave my feedback on this, in the SWICG charters repository.
The chaotic grassroots ecosystem currently lacks the chaordic organization required to make the essential paradigm shift.
However at any time this situation can drastically improve by concertive efforts. But only if we recognize that there is more than just tech to figure out. This is a social challenge that asks of everyone involved in the fediverse ecosystem to consider what their role is, and how their contributions relate to those of others and add up to cocreating the future of social networking together. The tendency in progressive circles is that minute differences in opinion and approach, are reason enough that people go their own ways. To the extent that this amounts to a self-defeating “We divide ourselves to be conquered” situation. We live in dark times, and it would be good if we considered “the table stakes” in our self-evaluation and willingness to cooperate with others.
State of the ActivityPub API
Section titled “State of the ActivityPub API”Work on supporting the ActivityPub C2S specification profile and ActivityPub API happens across the ecosystem. An overview of ongoing work should start with an honorable mention of the Andstatus client by Yuri Volkov, the first fediverse client software to delve deeply into C2S implementation challenges with help of Pleroma on the server-side, in 2018. The issue remains open to this day and is a good read for those interested in the history of C2S development. Other historic discussions can be found on the SocialHub community forum’s Client to Server (federated) category, which is also a good place to ask technical questions.
Sean Tilley wrote a good primer on C2S in Social Web Foundation is Betting Big on Client-to-Server API. The Social Web Foundation is co-founded by Evan Prodromou, co-editor of the ActivityPub specification, and author of the only book on the protocol ActivityPub: Programming for the Social Web (see this Book review by Terence Eden). Evan is chairing the ActivityPub API Task Force at the W3C.
SWICG ActivityPub API Task Force
Section titled “SWICG ActivityPub API Task Force”Today the SWICG ActivityPub API Task Force is the starting point for exploration. The top-level README provides a list of user stories where the task force is seeking feedback on from the developer community. When interacting with the task force it is highly recommended to browse the full list of (currently 70) open issues in the tracker to get a good overview of ongoing work. The biggest point of discussion are around authentication and authorization, and specifically relate to the use of OAuth 2.0 for the Social API. Most noteworthy is an unofficial draft of a Basic Profile for Social API Servers written by Evan Prodromou that provides a list of high-level specifications to conform to, including a detailed section OAuth 2.0.
Another document the task force is working on, proposed by Evan Prodromou, is the Server-Sent Events for the ActivityPub API unofficial draft. WHATWG Server Sent Events (SSE) is a broadly supported specification that allows a server to keep a one-way connection open to its clients, and is very easy to implement. SSE support would be a useful, optional extension for ActivityPub API implementers.
A concern I have with regards to the task force’s efforts is with the scope it is taking on for the ActivityPub API. The entirety of user stories that is represented reads more like a Swiss army knife than a comprehensive core that protocol implementers can readily focus on, and what is imho most needed to get the ecosystem unstuck. Sharing my concern is @kopper@not-brain.d.on-t.work, who favors a comprehensive design comparable to ATProto’s PDS and AppView split for respectively the C2S client and server. Their thoughtful article How not to regret C2S is a recommended read, and - even though now archived - Kopper’s ois project in Rust has interesting reflection on how to implement the ActivityPub API.
My recommendation to the task force would be not to fan out too quickly and first get buy-in on set of robust minimum specification profiles.
NLnet-funded C2S explorations
Section titled “NLnet-funded C2S explorations”NLnet is a Dutch non-profit organization that is tasked to distribute EU Horizon Europe grant funding for the Next Generation Internet initiative. Recognizing the importance of the ActivityPub API and C2S, in recent funding rounds NLnet has awarded R&D grants to a number of projects.
Steve Bate wrote ActivityPub Client API: A Way Forward in July 2025. This article provides probably the most comprehensive overview around implementing C2S, a MUST-read. With NLnet support Steve is working on the ActivityPub C2S Toolkit, a C2S client and tools for testing C2S server implementations against the full range of requirements laid out by the ActivityPub API. Another great project Steve is facilitating is FIRM, or Federated Resource Information Manager. This innovative experimental software contains a reference implementation for the C2S toolkit, but is also on the forefront of other important aspects of the ActivityPub specification that are important to make the paradigm shift described in this article, like elaborating good practices around the use of the linked data JSON-LD extensibility mechanism.
Nuages is the name of a C2S client software that conforms to the ActivityPub API, a progressive web app that will support microblogging and other platform services, and which is being developed by @django@mediaformat.org. The source code is not yet available, but the project README features a list of server implementations that support the ActivityPub API. It is based on testing server responses with Nuages:
☑supported,~partial support,xunsupported,-untested
Software RFC7591 RFC8414 CIMD CORS Actor oauth endpoints proxyURL sharedInbox Pleroma ☑ x - ~ ☑ x x FedBox ☑ ☑ ☑ ☑ ☑ ☑ ☑ Bonfire ☑ ☑ ☑ ☑ ☑ ☑ ☑ Friendica ☑ ☑ - x ☑ x x Onepage.pub ☑ ☑ - ☑ ☑ x - WordPress ☑ ☑ ☑ ☑ ☑ ☑ ☑
Then the Drupal content management system (CMS) will build a C2S Integration for their ActivityPub plugin, that makes Drupal a C2S server that can be used with multiple third-party fediverse clients (currently only AndStatus can interact directly). C2S support is funded as part of a larger set of UX improvements.
C2S implementations found in the wild
Section titled “C2S implementations found in the wild”In this section I will highlight some innovative fediverse projects from my C2S watchlist, who explicitly advertise their C2S support.
The Wordpress ActivityPub plugin announced C2S support in their v8.1.0 release, which exposes an ActivityPub API. In their own words “third-party Fediverse apps can now create, edit, and delete posts on your blog directly, the same way they would on a Mastodon account”. The feature is still experimental, and must be enabled. Here’s how to connect a third-party client. The C2S support was built by Mathias Pfefferle in this Pull Request.
Bonfire is among the most promising fediverse projects. Like Fedify it constitutes an ActivityPub application framework, and at the same time it is an expanding community platform that applies a very holistic vision of what online social networking entails, as can be gleaned from their innovative features. They are the only fediverse project that can be said to have made the paradigm shift, and are involved with a host of clients and partners in collaborative solution development. The Bonfire team found the C2S implementation straightforward, but are still struggling with authentication, and have chosen to support all the mechanisms used across the fediverse. They use their C2S support to interface with the Lauti community calender and to implement ActivityPub End-to-end encryption.
The Python Django ActivityPub Toolkit by Raphael Lullis is an interesting extension to the Django web framework that offers innovative ActivityPub features. It supports Linked Data and RDF, offers both push and pull-based federation, and focuses on standards-compliance. A mechanism of Proxy-based Resource Fetching allows C2S clients to fetch resources from remote servers.
FedBOX by Marius Orcsik is a C2S compliant server in Golang. It is positioned as a generic ActivityPub service, and a reference implementation for the GoActivityPub library, together with its Well-Known and Authorize services. A GoActivityPub: Client library is provided that can be used as either a C2S or S2S client. The C2S documentation explains how a REST(ful) client should be able to reference any object on the server, and led to the creation of FEP-6606: ActivityPub client to server collections addressing conventions. The documentation also includes a detailed specification compliance report for Client to Server interactions.
On the client side there is the ap command-line interface project by Evan Promodrou, which he initially created as companion code to his book, demonstrating how to implement the ActivityPub API. The project is actively updated, and is likely to reflect the latest insights from the SWICG ActivityPub API Task Force. Another C2S client software created by Evan is checkin, a sample app which demonstrates working with ActivityStreams geosocial objects, and makes calls to places.pub.
Though it is not a C2S or ActivityPub API implementation I’d like to give a special mention to Holos client app by Thomas who also develops the popular FediLab client application, among others. Holos uses a different and creative approach that bundles a full S2S server on the client-side, which communicates via websockets to a Relay server. A different approach, but equally powerful.
Raising the stakes
Section titled “Raising the stakes”Wicked problems are so hard to solve because they represent a Social mess that requires a prolonged many-pronged solution-oriented approach. Super wicked problems such as Climate Change are solved only by Emergence of the solution over time through the concertive efforts of countless individuals who unite on common causes.
Hypercapitalism is the single word I deliberately use to indicate humankind’s most wickedest problem. I consider it a root cause. This flawed system based on greed and bending of rules has brought us tremendous wealth inequality and gave rise to the “Epstein class”. A global oligarchy that stands to dominate us if we let them. Nothing less than Humanity and Freedom is at stake. We live in a time where technofascist robber barons see the world as their oyster, and want to remake it in their image.
These same people also happen to be the owner class of all advanced technology that our modern society is fully dependent on, including Social Media and and Artificial Intelligence platforms. Both incredibly powerful tools that are increasingly wielded for malign purposes, to undermine democracy worldwide, and to divide people with the objective to conquer them.
Against that backdrop we MUST reconsider the major achievement of the fediverse, an alternative social networking environment, that is created by the people for the people. Fediverse is much, much more than just an open technology landscape. It is a social achievement of great proportion. And it MUST grow and evolve as a social solution in the fight against these bad actors, and as a means to help overcome Big Tech(nofascism) and hypercapitalism. The fediverse has the power to unite people, where we are now being divided. Fediverse can bring the ability to cocreate at scale, and help create what humankind needs. Fediverse can be the online backbone of a value-based economy in a harmonious society.
These are the table stakes. We cannot squander what we have created today. Taking a pure technological approach to fediverse evolution is inadequate. We MUST include and consider the social aspects, and what the future has in store for us if we fail to fight the wicked problems of our time. We MUST consider our role in the larger whole, and how our two cents of contributions add up.