The ActivityPub Client-to-Server (C2S) protocol was envisioned as a cornerstone of the decentralized social web, along with the Server-to-Server (S2S) protocol. Standardized by the W3C in 2018, C2S defines how user-facing applications, such as mobile apps or web clients, and bots should interact with social servers using Activity Streams 2.0 and JSON-LD. In theory, it enables any compliant client to connect with any compatible server, offering a flexible, federated alternative to centralized APIs and proprietary integrations.
Yet despite its promise, ActivityPub C2S has seen minimal real-world adoption. Most Fediverse platforms — including Mastodon, the dominant implementation — have actively avoided supporting it. Instead, they expose custom APIs that tightly couple client behavior to server internals. This fragmentation has led to an ecosystem where client developers must build against bespoke interfaces, sacrificing interoperability, portability, and the broader vision of federation. The Mastodon team has advised against server developers implementing their client API, noting that it is often implemented incorrectly. In some non-Mastodon server implementations, this has led to security incidents.
The standard API approach [...] helps both client developers
and service providers by decoupling the API client from the API server.
Client developers can develop for multiple platforms with the same
codebase. - The ActivityPub book
Unfortunately, the rationale for C2S’s neglect is not unfounded. The base specification is minimal and leaves out many features considered essential for modern social applications, such as search, media uploads, real-time updates, bookmark and list (custom feed) management, and basic functionality like pending follower management. A few of these features have been described in a fragmented way in non-normative external documents like the W3C Wiki or informal Fediverse Enhancement Proposals (FEPs). Parsing JSON-LD and processing graph-based data introduces additional complexity for client developers. Moreover, since C2S is only supported by a few servers and the support is often partial, client developers have little incentive to invest in the protocol, and vice versa, creating a classic chicken-and-egg problem.
This article suggests that C2S can still fulfill its original purpose if it is extended in a principled, minimal, and interoperable way. By addressing critical gaps through community-led FEPs and learning from real-world implementations like the Flowz client, we can make C2S a viable foundation for a new generation of rich, user-friendly, and decentralized social applications.
I'll examine the technical mechanics of C2S, the reasons for its rejection by major platforms, its current limitations, and the benefits it offers when properly extended. I'll also explore how FEPs provide a path forward, and how Flowz serves as a proof-of-concept. The goal is to make the case for a revitalized C2S, not necessarily as a competitor to existing proprietary client APIs, but as a shared substrate that restores the promise of client choice, server diversity, and user empowerment on the Fediverse.
Understanding ActivityPub C2S
The ActivityPub Client-to-Server (C2S) protocol defines how social media clients communicate directly with their servers in a decentralized social network environment. At its core, the protocol operates by clients sending activities (creating posts, liking content, or following users) through HTTP POST requests to the actor's outbox endpoint on the server. This outbox serves as the authoritative stream of all activities generated by the user. Conversely, clients receive incoming data, such as notifications or messages, by issuing HTTP GET requests to their inbox endpoint, where the server queues activities directed to them.
To secure these interactions and ensure that only authorized clients can act on behalf of users, OAuth 2.0 is unofficially recommended for authentication and authorization, although other approaches are allowed. This ensures that clients present valid credentials before they can post or retrieve activities, safeguarding user accounts and privacy.
Underpinning the data exchange is the ActivityStreams 2.0 vocabulary, a standardized and extensible JSON-LD format. This data model allows social interactions to be represented as structured, linked objects (such as Create, Like, Follow, and more) that clients and servers can understand and manipulate. The use of JSON-LD facilitates semantic richness and flexibility, allowing implementations to extend or customize objects while maintaining interoperability. Clients can follow links embedded within activities to retrieve additional context or related objects, enabling a dynamic and flexible social data graph (referred to colloquially as the follow your nose design in contrast to predefining URI structures).
The design intent behind C2S is to foster true universality: a single client application should be able to connect to any server that complies with the standard without requiring server-specific customizations or proprietary API adaptations. This stands in contrast to the current fragmented ecosystem, where many servers offer unique APIs or partial implementations that fragment the user experience and limit client portability. By adhering to the C2S protocol, clients can operate seamlessly across diverse platforms, thereby reinforcing the decentralized, federated nature of the social web and promoting user freedom and choice.
Mastodon’s Resistance and the Rise of an Alternative API Standard
Mastodon, as the largest and most influential ActivityPub implementation, explicitly rejected support for the Client-to-Server (C2S) protocol in 2019 when the development team expressed significant reservations. One of their primary criticisms was that the C2S specification was too barebones, lacking crucial features necessary for a rich user experience. Specifically, they pointed out the absence of support for notifications, search capabilities, timelines, and muting functionalities. As a result, clients implementing C2S would be forced to handle a disproportionate amount of complex logic themselves, which they deemed impractical.
The ActivityPub C2S spec is incredibly barebones. No notifications (as separate from home feed -- it's all mixed together in "inbox"), no search, no autocomplete, no domain blocking, no muting (as opposed to blocking), etc etc. You'd end up defining so much custom vocabulary and endpoints that you might as well just use the Mastodon REST API. - Issue Discussion, Eugen Rochko (@Gargron)
The Mastodon team highlighted the substantial implementation burden that adopting C2S would impose. They stated that integrating C2S "would require rebuilding Mastodon’s architecture," a daunting prospect with no immediate or "clear user benefit." This viewpoint underscored their concern that the costs in development effort and architectural changes would outweigh the advantages. Mastodon already had a client API that met their needs, and this also played a role in the decision.
Over time, the dominance of Mastodon's proprietary client API further complicated the landscape. This API effectively become the de facto standard for client-server interactions within the Fediverse, creating a strong incentive for servers and clients alike to maintain compatibility with it. Consequently, this ecosystem inertia discouraged wider adoption of the C2S protocol, perpetuating a cycle where C2S remained underutilized. Critics argue that this fragmentation has limited the potential for true interoperability and stifled innovation that a unified C2S implementation could enable.
What’s Missing: Deficiencies of Raw C2S
Despite its promising design, the limitations of ActivityPub's Client-to-Server (C2S) protocol represent significant technical limitations that hinder its widespread adoption. As discussed earlier, among the most notable gaps are the lack of features such as search capabilities, bookmark management, list management (custom feeds), media upload functionality, real-time streaming, and actor authentication and authorization.
Some of the gaps are quite surprising. For example, the ActivityPub specification defines the Announce activity (used for actions like "boosting" or "reblogging" content) in the server-to-server (S2S) protocol, but it does not explicitly specify how Announce should be handled in the client-to-server (C2S) API.
These missing components are crucial for providing a seamless and feature-rich user experience, especially when compared to the comprehensive offerings of proprietary APIs like Mastodon's.
On the client side, developers face substantial complexity. The protocol’s reliance on JSON-LD means clients must efficiently parse complex linked data graphs, resolve context and linked objects, and handle various Activity Streams 2.0 types. This steep learning curve and the overhead involved in managing linked data structures can slow development and discourage client authors from embracing C2S. The other option, commonly chosen by developers because it seems easier, is to process all ActivityPub messages as plain JSON (not as JSON-LD). Treating ActivityPub messages as plain JSON undermines extensibility because it prevents the use of JSON-LD features like context definitions, leading to potential property name collisions and making it difficult for implementations to reliably interpret or extend messages.
Performance also remains a concern. Since C2S interactions are primarily HTTP-based and stateless, frequent polling and data fetching can lead to slower responsiveness and higher latency compared to stateful alternatives such as WebSocket-based protocols. This can degrade the user experience, especially for real-time notifications and timeline updates. On the other hand, this may not be a critical issue for smaller servers and polling may suffice.
Why C2S Still Matters
The potential of ActivityPub’s Client-to-Server (C2S) protocol remains compelling and essential for the future of decentralized social networking. In an ideal world, C2S would provide true interoperability, enabling clients to seamlessly connect and operate across a wide variety of servers without the need for bespoke integrations or server-specific adaptations. This universality brings us closer to the original vision of the Fediverse, a truly federated social web where users are free to choose their client and server independently, without being locked into a single software ecosystem.
Beyond interoperability, C2S unlocks significant innovation potential by decoupling client development from the complex and often fragmented server-side logic. This separation fosters an environment where developers can experiment with new user interfaces and interaction models without having to reverse engineer or replicate proprietary APIs. Such freedom encourages creative approaches to social software design, ultimately leading to more engaging, accessible, and flexible experiences for users.
Adopting and enhancing C2S aligns deeply with the core principles of decentralization that underpin the Fediverse. By reducing reliance on single-server APIs, C2S strengthens the resilience and openness of the ecosystem. It empowers users with true data ownership, the ability to switch clients or servers without losing their social graph, and freedom from vendor lock-in. These qualities are crucial to sustaining a vibrant, diverse, and user-centric decentralized social network.
As community-driven Fediverse Enhancement Proposals (FEPs) continue to address current gaps in the protocol, and as pioneering server projects prioritize C2S support, there is reason to be optimistic. C2S has the potential to transform the social web landscape into one that is more interoperable, innovative, and ultimately empowering for users worldwide.
The good news is that it is possible to create social web user interfaces using C2S. The experimental Flowz client demonstrates some of these possibilities, but there's much more that could be done.
C2S Path to Viability
Extending C2S via FEPs
There are numerous existing FEPs that could be included in an extended C2S definition. To make the quickest progress, I believe we should focus on the minimal set of extensions and fixes to the existing ActivityPub C2S definition that will support the development of clients that have similar features to the current client user interfaces based on proprietary APIs. Some of these essential FEPs would support client access to an actor's pending followers (fep-4ccd) and actor blocks (fep-c648).
There are also several proposals related to managing reply/conversation collections (fep-76ea, fep-171b, fep-f228). An extended C2S API would need to choose one of these or develop something similar to be able to effectively and efficiently implement reply browsing (and conversation backfilling).
Furthermore, additional FEPs are needed to specify C2S Announce behavior (very similar to S2S Announce) and user-managed collection references (to allow "follow your nose" link traversal from an actor document). Functionality like media upload (currently described in the W3C wiki) would also be good candidates for new FEPs.
Mastodon Client API Adapter
One of the challenges of breaking the "chicken and egg" causal cycle for ActivityPub C2S is having a way for C2S client developers to have access to potential users in the near term.
Creating an adapter that maps the ActivityPub Client-to-Server (C2S) API to the Mastodon client API offers an interim solution for integrating ActivityPub-native clients with Mastodon-based servers. Instead of waiting for server implementations to support ActivityPub C2S directly, potentially a complex and long-term process, this adapter would allow developers to target the standard ActivityPub C2S interface while still interoperating with existing Mastodon-compatible servers. The adapter would translate standard ActivityPub client requests into equivalent calls to the Mastodon client API, acting as a bridge between the emerging C2S ecosystem and the dominant Mastodon-compatible infrastructure.
This adapter could be deployed as a standalone proxy service that sits between an ActivityPub C2S client and a Mastodon (or Mastodon-conformant) server. Clients would communicate purely in ActivityPub, posting Create activities, sending Follow requests, or fetching objects, while the adapter would handle all translation and state tracking needed to invoke the corresponding Mastodon API endpoints. The adapter would also map identifiers between ActivityPub and Mastodon, preferring to use existing Mastodon URIs where possible. Since the adapter encapsulates all Mastodon-specific logic, clients can remain cleanly decoupled from Mastodon’s implementation details, enabling reuse across any conformant ActivityPub C2S system.
A key benefit of this approach is that it requires no modifications to existing Mastodon servers. This preserves compatibility and lowers the barrier to experimentation, allowing developers to start building C2S-first clients today while the server ecosystem gradually evolves. Additionally, the adapter could support other servers that implement Mastodon-compatible APIs, not just Mastodon itself, enabling a broader compatibility layer.
Ideally, this adapter would be temporary and used only until native support for ActivityPub C2S becomes common among server implementations. But during this transitional phase, it serves an important strategic role: enabling client developers to adopt the standard API and data model early, without sacrificing interoperability. It also creates space for evolving richer, more expressive client interactions not limited by the constraints of the Mastodon API, all while maintaining compatibility with today's Fediverse infrastructure.
Roadmap for C2S Adoption
To realize the full potential of ActivityPub’s Client-to-Server protocol as a viable and competitive alternative to proprietary APIs, a coordinated, multi-faceted effort is essential. This roadmap outlines key steps and priorities to drive broader adoption and maturation of C2S in the Fediverse ecosystem.
Finalizing and Stabilizing Core FEPs
The foundation of C2S adoption lies in the creation, completion and stabilization of critical Fediverse Enhancement Proposals (FEPs). These community-driven extensions should address significant gaps in the current specification. Prioritizing existing and new C2S FEPs to achieve stable draft status (if not final status) will provide clear, interoperable guidelines for both server and client implementers, reducing fragmentation and uncertainty.
Building an AP C2S-to-Mastodon API Adapter
Recognizing Mastodon’s dominant position and extensive existing user base, an important transitional strategy is the development of a C2S adapter that translates the ActivityPub C2S protocol and its extensions into Mastodon’s proprietary client API. By bridging C2S clients to the Mastodon API, this approach would enable immediate access to a large user base, allowing C2S clients to thrive in the near term.
Collaborating with Server Developers
A successful C2S ecosystem requires server implementations that fully support the core protocol and its extensions. Active collaboration with server projects that already implement or are planning to implement C2S, especially domain-independent ActivityPub servers like Vocata, rdf-pub and ActivityPods, is crucial. Working with these developers to ensure conformance and interoperability testing will help establish a solid, reliable server-side foundation for C2S clients. This engagement will also surface practical challenges and refinement opportunities early in the adoption cycle.
Test suites like the activitypub-testsuite can be used to help developers know if they are conformant the extended C2S specifications.
Encouraging Diverse Client Development
For C2S to gain traction, a rich ecosystem of clients targeting various social and application domains must emerge. Encouraging development of C2S-native clients—whether focused on microblogging, media sharing, event management, or other Fediverse use cases—will demonstrate the protocol’s versatility and user experience potential. Such diversity will drive innovation and provide valuable feedback on real-world usability and extension needs, further refining the specification.
Developing reusable ActivityPub component libraries is another opportunity to support client development. The ap-components is an early project that demonstrates some of the possibilities.
Together, these strategic steps form a pragmatic, incremental path toward widespread C2S adoption. By stabilizing the protocol extensions, building a solid server foundation, fostering diverse client innovation, and bridging existing server ecosystems, the Fediverse community can unlock the promise of a truly interoperable, extensible, and user-focused Client-to-Server protocol. This roadmap not only addresses current technical and ecosystem challenges but also positions C2S as a sustainable standard for the decentralized social web’s future.
Case Study: Flowz C2S-based UI
Flowz is an experimental client for the ActivityPub Client-to-Server (C2S) protocol, created to showcase the protocol's practical viability and to provide a flexible foundation for exploring future enhancements. Its architecture is deliberately modular and built with a strong emphasis on standards compliance, allowing it to interact with any server that implements the core C2S specification. This includes servers that support a wide range of social application, such as microblogging, media sharing, and event or meeting coordination. The current Flowz UI is mostly focussed on microblogging. However, by basing its functionality on general C2S compatibility instead of relying on proprietary server APIs, Flowz can be extended to other types of applications as well.
See the following demonstration video for a quick example of the rough Flowz prototype.
The motivation for Flowz arose from a practical need: after building an ActivityPub server, I wanted to use it as my daily driver in the Fediverse. That meant I needed a user interface. The usual options, building a server-specific client and API, or implementing the Mastodon client API to use an existing Mastodon-compatible app, felt limiting. Instead, I chose to build on the C2S protocol. Although the standard C2S feature set is relatively minimal, extending it seemed both feasible and broadly beneficial, not just for my own server, but for the wider AP ecosystem.
A core objective of Flowz is flexibility and graceful degradation. Even when connected to a server that supports only the minimal core C2S functionality, the client still delivers a reasonable user experience. Users can perform essential actions such as reading timelines and posting updates. However, where Flowz really shines is when it connects to servers that offer extended C2S capabilities. These may include implementations of community-driven Fediverse Enhancement Proposals (FEPs) or other extensions beyond the base protocol. In these cases, Flowz can deliver a feature-rich experience on par with, or exceeding, what current Mastodon-based clients offer, supporting richer media presentation, customizable feeds, and future functionality like general actor relationship management (not just Follow relationships). This flexibility highlights the long-term promise of the C2S model: enabling powerful, user-centric applications in a decentralized social web.
Though still in alpha and not yet publicly released, Flowz already supports a growing set of features, with more planned. These include:
- Timelines
- Home (from the actor’s inbox)
- Local (from public activities in the shared inbox)
- Post Editing (Rich text editor, TBD)
- Post Rendering
- Supports various object types (text/documents, media documents, event, place, questions, generic)
- Mermaid diagrams
- Map rendering (using Leaflet) for
Placewith a location. - Syntax-highlighted code blocks
- iCalendar (RFC 5545) Event downloads
- Handles attachments including event, place, and media types
- Can show ActivityPub JSON-LD
- Post Interactions
- Announce (via extension), Like, Delete (own posts), and Reply
- Actor Profiles
- Includes timeline rendering from the actor’s outbox
- Actor Interactions
- Follow, Unfollow, Block, with Ignore to be determined
- Search (URI-based and simple extended search)
- Bookmark Collections
- Custom Collections (planned)
- Notifications
- Currently implemented via polling
- Can be extended with websockets or SSE in the future
- Graceful Degradation
- Ensures usability even with limited server features
Authentication and authorization are also being addressed with flexibility in mind. While no single standard approach is required by ActivityPub, Flowz is designed to support multiple pluggable authentication and authorization strategies, allowing it to adapt to different server environments and use cases.
To explore the flexibility of the extended C2S protocol, other UIs may be developed that focus on use cases like online marketplaces, task (to do) management, or a simple online game, as a few of many possible examples. During the Flowz development, I'll be looking for opportunities to extract general-purpose C2S-related functionality to make it easier to reuse in other specialized user interfaces.
In short, Flowz is both a working client and a research platform. Although it's an early work-in-progress, the hope is that it will encourage C2S evolution through real-world testing, help refine extension FEPs, and encourages a vision of a Fediverse built on open, extensible, and interoperable standard, where clients and servers can grow together without locking users into closed ecosystems.
Conclusion
ActivityPub’s C2S protocol, though long sidelined, holds the key to reclaiming client diversity and interoperability. With targeted FEPs and pioneering implementations like Flowz, the Fediverse can break free of proprietary client APIs and monolithic client/server implementations and empower a new wave of social web innovation.