When Elon Musk bought Twitter in 2022, researchers realized their professional lives were housed on a platform they no longer trusted. They turned to Bonfire, an open source toolkit used to assemble online social spaces for communities. One of its two core contributors, Ivan Minutillo, saw the science community move from Twitter presence to Twitter activism: working to replace the platform and preserve their work.

The discussion soon shifted toward an open, federated replacement for platforms like ResearchGate and Academia.edu. Then, to academic publishing: A standard journal charges a submission fee, charges readers to get past the paywall, and pays authors nothing. “It is so exploitative,” says Minutillo. What began as a search for social networking software became a different question: What if there were federated open journals, where researchers organize and publish as peers?

The Open Science Network, a scholarly edition of Bonfire, comprises communities tackling that question. It is governed by researchers, and a living lab at the University of Warwick brings them to the design table with librarians and software engineers. Any university, society, lab, or collective can run its own server and stay connected to the others. Sciety, an open evaluation service, is one result: Each article page houses direct conversations about preprints and peer reviews, which become citable objects, so the conversation about a paper’s production becomes part of the scholarly record.

Commercial research networks exist; what none of them offered was governance by the researchers themselves. The software underneath the alternative was, in part, paid for by the public: more than 70 projects working with ActivityPub have been funded through NGI Zero programs, themselves made possible with financial support of the European Commission and an allocation of public funds. ActivityPub is the protocol that connects the Fediverse – the federated social media and networks built upon it. And network autonomy in this context means having material to build with, and enough of it that a community can shape its own space.

The Standard That Almost Did Not Happen

ActivityPub became a W3C Recommendation on January 23, 2018, published by the Social Web Working Group. Its lead author and co-editor was Christine Lemmer-Webber, who spent most of the previous three years on it and described the day it shipped as a mix of elation, relief, and burnout.

A dozen decentralized social projects were already running, each with its own approach and years of investment, and none of them could talk to one another. Lemmer-Webber’s early work on ActivityPub largely consisted of going around to those projects to argue for a single standard that everybody would ship. “It is a little bit like if you said, let’s try to get the Linux kernel and the BSD kernel to agree on one kernel,” she says. Getting people to compromise isn’t easy when they already have an investment in how something is done.

It nearly ran out of time. The working group’s charter was expiring, and the W3C wasn’t going to renew it again. What saved the standard was a problem elsewhere: Mastodon, with somewhere between half a million and a million registered accounts, was running on an older federation technology called OStatus that leaked private messages. Lemmer-Webber describes ActivityPub as offering Mastodon something closer to the privacy level of email, while OStatus offered “please don’t look at this message.”

Plurality, and the Shape Everybody Copied

Funded ActivityPub work covers video, photographs, music, forums and link aggregation, events, live streaming, podcasting, publishing platforms, wikis, and, soon, code forges. It also covers the unglamorous connections that allow any of it to interoperate: test suites, conformance frameworks, and the tooling projects used to check that they federate correctly. Rather than the single platform researchers initially sought, public money funded a catalog of parts.

ActivityPub shipped two halves: a server-to-server protocol for federation and a client-to-server protocol for applications. Only the first half was adopted; Lemmer-Webber and her specification co-editor Jessica Tallon had expected general-purpose social servers with specialized clients on top, matching where the industry seemed to be heading at the time. What the ecosystem built instead is close to the opposite – specialized servers, each one an app in its own right, where developers “make the federated version of the named proprietary centralized thing” (e.g., Mastodon as the federated version of Twitter).

Bonfire arrived, from another direction, at the same diagnosis of the ecosystem’s central limitation: Federating an application with copies of itself is not interoperability. “I’m creating a new app for, let’s say, book reviews,” developer Mayel de Borniol explains. “People can install their own server of book reviews, it will federate with all the other book review servers, and that’s great.” But a person on the Fediverse should be able to hold one account and follow anybody, he argues, rather than opening a new account for each of 20 different applications.

The reason Bonfire keeps building sideways instead of upward, in Minutillo’s estimation, comes down to the difference between social media and social networks. Social media is the global town square, which doesn’t exist in real life; you can’t put everyone in one square and expect a conversation. A social network mirrors the relationships people already have.

Federated open journals are one version of that. So is the work Bonfire built for Jacobin’s German edition. When the magazine asked readers to fund a relaunch, 1,015 backers paid and kept going until they unlocked the next tier: a protected community platform where they could vote on what the magazine should cover. Six months of co-design later, jacobin.social opened. Rather than replying only in comments beneath finished pieces, the community is now integrated into the magazine’s publishing process from the start.

Writing in Bonfire’s case study, the German edition’s assistant editor Magdalena Berger describes the choice to open as political rather than merely technical: The magazine wanted something that “couldn’t be switched off by a foreign government or bought out by a billionaire.” Out of that collaboration came embedded federated comments, with a widget that turns any web page into a federated conversation. Publishers can moderate, but the artifacts live on an account the reader already holds elsewhere, on a network the publisher does not own and cannot revoke.

Minutillo sees great potential for the application of those networks. Sensors can publish a town’s readings into a community’s space, so municipal open data becomes something residents can see and argue about. Schools can use species-tracking tools to report what is growing and living in the area: a river or forest as an actor on the Fediverse that you can follow. Fab labs and tool libraries can exchange what they hold between neighborhoods without a central platform in the middle, because nobody needs a warehouse when the good screwdriver is already at somebody’s house. None of it has a proprietary version, because none of it would earn anything.

How Far Control Actually Goes

The usual claim for federated social media is that it puts users in control. But this runs into the problem both interviewees name as the hardest, from opposite ends of the stack. Asked what remains unsolved, Minutillo doesn’t pick a technical feature: “the Fediverse is hard for the majority of people,” he says. “It is hard to understand. It is hard to use.”

Control today mostly comes from who runs the server. On a large instance, an administrator decides which other servers to federate with, what the rules are, and whether the server persists. Bonfire is, however, wary of recommending self-hosting as the ideal solution: “often that just means renting a server from a big company,” de Borniol says, “and then you’re on your own with the maintenance.”

European institutions have already run the experiment on what happens when nobody owns server management. In 2022, the European Data Protection Supervisor (EDPS) launched a pilot of EU Voice on Mastodon and EU Video on PeerTube. It was meant to run for a year, and then extended to two. By the end, EU institutions were the largest group of public bodies on the Fediverse anywhere. But when the pilot ended, and the server needed a permanent home, no other EU body would take over the servers. De Borniol declines to read the closure as a failure: Shutting down can be the right call, he argues, and better than keeping a server nominally alive while nobody stays on top of moderation and the instance becomes a source of spam. What matters is whether people were given enough warning to export data and move.

The practical middle is a cooperative. Lemmer-Webber is on social.coop, one of several instances where members contribute money and take part in decisions, and that money pays for technical maintenance that would otherwise require volunteers. Bonfire is a member of Co-op Cloud – a community first and a set of deployment tools and recipes second. Its other members include hosting cooperatives such as CoQuest, which hosts jacobin.social and helps maintain the recipe that enables straightforward Bonfire deployment. A community that needs managed hosting gets infrastructure people and software developers in the same conversation when something breaks. Bonfire’s phrasing is “do it together” rather than “do it yourself.”

Lemmer-Webber’s answer to what remains unsolved starts with an admission. “ActivityPub was not supposed to be as instance-centric as it is.” She originally envisioned a distributed social network where identity was decoupled from domain name, so moving between instances would be ordinary. But the ecosystem adopted ActivityPub in a client-server shape and then settled into it.

What does exist today is account migration. De Borniol names it first when asked what organizations must have before opening a community space: Members need to be able to export their data, move their account, and bring their follower networks with them. This keeps communities protected during shutdowns and sets the stage for portable identity and content.

The version Lemmer-Webber wants is harder, and she is realistic about the odds. It comes from capability security, a model whose one-line summary is that if you don’t have it, you can’t use it: A program gets only what it is handed rather than everything you can reach, and that grant can be revoked. Bonfire’s Archipelago mode lets an instance maintain a list of servers and people it will federate with, rather than only a list of those it blocks; communities can link into an archipelago of islands with shared rules instead of connecting to everything by default. But capability security takes it a step further. Applied to a calendar, a scheduling program books a free slot without seeing what fills the other ones. Applied to moderation, it would mean control that does not run through instances at all, but it is handled directly by the user. But “at this point, people have become very entrenched in the instance mindset,” Lemmer-Webber says.