FR#156 – Share Where?

Laurens uses Mastodon's new Share button - which frames Mastodon "not as one implementation of a shared protocol but as a platform" - to explore protocol ownership, showing how "The fediverse built its federation layer on an open standard, but left the client layer to be captured by its dominant provider". That dominant provider is Mastodon, and "The more tools and integrations that get built on top ... the deeper the lock-in becomes."

The basic problem: "The ActivityPub protocol specification consists, roughly, of three parts... Crucially, almost nobody has implemented the third part", which covers "the Client-to-Server part of the protocol, also known as the ActivityPub API".

As a result, "Every Mastodon app ... talks to your server through the Mastodon API", and it's the same for Lemmy, Misskey, etc: "The fediverse has no shared client protocol, only a collection of proprietary APIs tied to individual server implementations."

As Mastodon is so dominant, "Its API functions as a shadow standard... 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."

Ironically, "The original feature request to implement the ActivityPub client-to-server protocol on Mastodon, filed in 2019, warned exactly this ... "our proprietary API will become the de facto standard"."

The share button will simply reinforce this dominance further, equating Mastodon software with the Fediverse network: "The button says “Share on Mastodon,” not “Share on the fediverse.”"

In fairness, "the ActivityPub social API ... specification has real deficiencies...a real problem, but [one] ... that the dominant software provider has the most power, and the most responsibility, to help solve" (and doesn't). There is a taskforce, but Mastodon "has not signaled interest in implementing what the task force produces".