Mastodon recently launched an official share button for websites, hosted at share.joinmastodon.org. Unlike centralized platforms, the fediverse has no single URL to link to. A user’s account could be on any of tens of thousands of servers. So when someone clicks on the “share” button on a website, it requires figuring out what the correct server is this URL should be shared to. Third-party solutions have existed, but none really caught on. Mastodon’s answer is a branded widget that website owners can embed, complete with the Mastodon logo.
The final sentence of the blog post announcing the button is the most interesting: “We’re looking forward to seeing the Mastodon logo on more websites, possibly alongside other social media platforms, and maybe even as the main sharing link.” The framing puts Mastodon in the row of icons next to Twitter, Facebook, and LinkedIn, not as one implementation of a shared protocol but as a platform.
The share button works through Mastodon’s own API and infrastructure, not through ActivityPub. It is a direct consequence of a design choice made years ago: the fediverse has a standardized protocol for servers talking to each other, but no standardized protocol for how users interact with their servers. That gap has been filled, in practice, by Mastodon’s API. The Mastodon API is open source, but it is not an open standard. It is designed, maintained, and changed by one project, without input from the rest of the ecosystem. The fediverse is only half built on an open standard. The layer for server-to-server communication is standardized. The interface layer, the part users actually touch, is used via proprietary APIs.
The ActivityPub protocol specification consists, roughly, of three parts. First, defining the structure of ActivityPub objects, which says things like “each object should have an id in a certain format.” Second, defining how servers exchange information and send ActivityPub objects to each other. This is the Server-to-Server part of the protocol. Third, defining how servers exchange information with clients. This is the Client-to-Server part of the protocol, also known as the ActivityPub API. Mastodon, and most of the fediverse for that matter, have implemented the first two parts of the ActivityPub protocol. Crucially, almost nobody has implemented the third part.
Every Mastodon app you have ever used, whether Ivory, Ice Cubes, Tusky, Phanpy, Elk, or any other, talks to your server through the Mastodon API, and none of them use ActivityPub’s client-to-server protocol. The same goes for other parts of the fediverse: Lemmy has its own API for clients, Misskey has its own API, and so on. The fediverse has no shared client protocol, only a collection of proprietary APIs tied to individual server implementations. Among those platform-specific APIs, Mastodon’s is the one that matters most, because Mastodon dominates the fediverse’s user population. Its API functions as a shadow standard. The entire ecosystem of third-party clients, tools, and integrations is built against it.
Server software that wants to be usable needs clients. Since clients already exist for the Mastodon API, alternative server implementations end up cloning it just to usable. If you want your users to be able to use Ivory or Tusky, you implement the Mastodon API. Most microblogging does, GoToSocial, Pleroma and its fork Akkoma, Friendica all implement the API or provide compatibility for it. Some of the Misskey forks, such as Sharkey, implement both the Mastodon API and the Misskey API, allowing you to use Mastodon-oriented clients like Phanpy with the *key servers. The Lemmy and Misskey APIs have their own client ecosystems, but neither exerts cross-ecosystem force the way Mastodon’s does.
Even software projects that exist specifically to offer something different from Mastodon end up dependent on its API. They must conform to a restricted interface designed around Mastodon’s specific model of microblogging. Features that don’t fit within Mastodon’s assumptions, such as emoji reactions, non-chronological timelines, or forum-style threading, either cannot be exposed through the API at all or require clients to special-case every server that supports them.
The original feature request to implement the ActivityPub client-to-server protocol on Mastodon, filed in 2019, warned exactly this: “since Mastodon is the biggest fish in the pond, a lot of client developers choose our proprietary API. The risk is that our proprietary API will become the de facto standard when it comes to client-to-server communication in the Fediverse.”
A news website wants to let readers share articles on the fediverse. Generic “share on the fediverse” tools do exist, built by third-party developers. But none of those tools have the institutional weight, the brand recognition, or the discoverability that would convince a publisher to actually embed them. When a news organization decides to add share buttons, they are looking for something with the same standing as the Twitter or Facebook buttons already on their page. Mastodon is the only fediverse project that can offer that. The only realistic share button for the fediverse is a Mastodon share button, and it comes with Mastodon’s logo and routes through Mastodon’s infrastructure.
First, it equates the software with the network. The button says “Share on Mastodon,” not “Share on the fediverse.” A reader who uses Misskey, Pleroma, GoToSocial, or any of the dozens of other fediverse server implementations sees a brand that is not theirs. A server operator who runs a non-Mastodon server and does not want to display the Mastodon logo on their community’s behalf has no real alternative.
Second, it reinforces the dominance cycle. If publishers embed a Mastodon share button, users on non-Mastodon servers have a worse experience or no experience at all. This pushes both users and server operators toward Mastodon compatibility, further entrenching APIs that are not open standards as the interface default.
Should a news website also add a “Share on Pleroma” button? A “Share on Misskey” button? A “Share on GoToSocial” button? If the network actually ran on a shared client protocol, a single generic share button with real institutional backing would be possible, because it would be a protocol-level feature rather than a software-level product. The fact that sharing must be routed through a specific platform’s infrastructure and branding is a direct consequence of the missing standard.
Mastodon’s decision not to implement the ActivityPub social API is not arbitrary: the specification has real deficiencies. Eugen Rochko, Mastodon’s founder, described the client-to-server spec as “incredibly barebones,” pointing out that it lacks definitions for notifications, search, autocomplete, domain blocking, muting, and many other features a social application needs. His conclusion: “You’d end up defining so much custom vocabulary and endpoints that you might as well just use the Mastodon REST API.”
The critique is right about the state of the spec. A developer attempting to build a full-featured social application against just the spec would need to invent most of what makes the application usable. The ActivityPub client-to-server spec defines a write interface (post activities to your outbox and the server processes them) but leaves enormous gaps in everything else a client needs. There is no standard way to get a home timeline, no notification system, no search, no media upload mechanism in the normative spec. Rochko made a defensible, and probably correct, engineering decision given the state of the spec at the time.
But the consequence of that decision is a self-reinforcing loop. The spec is incomplete, so Mastodon built its own API. Mastodon’s API became the de facto standard because Mastodon dominates the network. Because the Mastodon API is the de facto standard, there is no pressure to complete the open spec. And because the open spec remains incomplete, the next project that comes along faces the same choice Mastodon faced, except now they also have to clone the Mastodon API to access the existing client ecosystem. The incompleteness of the standard is a real problem, but it is also a problem that the dominant software provider has the most power, and the most responsibility, to help solve.
Making the situation even more complicated is that there is no consensus on what a functional client-to-server protocol for the fediverse should actually look like. The problem is not simply “someone needs to finish the spec.” This has been a live conversation among ActivityPub developers in recent weeks.
One criticism of naive C2S implementations is that simply exposing ActivityPub endpoints on top of an existing Mastodon-like server doesn’t buy you much. The developer kopper has called this the “JSON-LD flavored Mastodon API” problem: the result is an API just as rigid and limited as the proprietary one, but without the benefits of being purpose-built. If unmodified Mastodon were to simply replace their API with C2S, you still would not be able to send emoji reactions to posts. The Mastodon database does not have the concept of an “emoji reaction on a post.” The real gain from C2S, kopper argues, is the ability to separate data hosting from data interpretation. The server becomes a nearly stateless data host, and a separate client layer handles interpretation, indexing, timelines, and moderation.
Fedify developer Hong Minhee pointed out that when you map the architecture onto familiar terms, the “dumb server” is a database, the “client layer” is an application server, and the “frontend” is the actual client app. That is the current architecture with the labels shifted one layer down. The interesting question is which interface gets standardized. In kopper’s model, the answer is the bottom boundary, between data host and client layer, while frontends remain locked to specific client implementations. The interoperability promise of C2S, the idea that any app could connect to any server, gets pushed one layer down, out of reach of the end user.
The disagreement is really about what portability means: portability of data, portability of identity, portability of interface, or some combination.
The most organized attempt to change the situation is the ActivityPub API task force, part of the W3C Social Web Community Group, led by Evan Prodromou. The task force has defined over 30 user stories covering the gaps in the current spec: OAuth standardization, feature discovery, media upload, notifications, search, content filtering, moderation tools, and more. One of its explicit non-goals is to standardize the Mastodon API. The goal is to make the ActivityPub social API comprehensive enough that client developers can build against it and server developers can implement it, rather than codifying Mastodon’s API as the standard.
The task force is still in early stages. Many of its key deliverables are marked “TBD.” And Mastodon, the one implementation whose participation would most change the situation, has not signaled interest in implementing what the task force produces.
Imagine if the only way to build an email client was to implement Gmail’s API. Thunderbird, Apple Mail, Outlook, and every other client would need to clone Gmail’s interface contract. Email servers that wanted their users to have access to third-party clients would need to expose Gmail-compatible endpoints. A “share via email” button on a website would route through Gmail’s infrastructure and display the Gmail logo. Anyone running their own mail server would still see Gmail’s branding when they shared content.
This is approximately the situation in the fediverse today, with Mastodon in the role of Gmail. The difference is that email has IMAP and SMTP, client protocols that are not only standardized but universally adopted. Every email server implements them and every email client expects them. The protocols are not just specified, they are legitimate, in the sense that no serious email provider would consider not supporting them. The fediverse has no equivalent. The ActivityPub social API is specified but not adopted, and it lacks the legitimacy that would make adoption likely.
The problem here is not with the share button itself. The fediverse built its federation layer on an open standard, but left the client layer to be captured by its dominant provider. The more tools and integrations that get built on top of that proprietary interface, the deeper the lock-in becomes.
