ActivityPub is at an interesting place. Since its intial adoption by Mastodon in 2017, the standard has become all but ubiquitous across the Fediverse. In less than seven years, it has become the most-used protocol across the entire network.

According to FediDB, the ActivityPub side of the Fediverse is now used by nearly 10 million people, across more than 27,000 servers. FediDB also tracks 48 different platforms leveraging ActivityPub in some way. With Threads actively doing work their own implementation, these stats are likely to skyrocket, in more ways than one.

This kind of growth is a really positive sign for the network, as it suggests that widespread adoption of the Fediverse might actually be feasible. In order to get there, though, a number of developers have looked at ActivityPub and wondered: what could we do to make this better?

What does ActivityPub need?

While the Fediverse has seen an explosion of features involving chat, multimedia, live streaming, groups, events, and more, some people would say that the network suffers from a few glaring omissions.

In light of some of the developments taken on by Nostr and Bluesky, ActivityPub can feel downright limited in terms of what platforms in the Fediverse can do today:

• Bluesky makes server migration dead simple for users, leading to a process that feels seamless and non-intrusive.
• Bluesky offers a stackable moderation system that allows people to subscribe to labeling services and help each other curate and filter the network.
• Nostr benefits from a relay system that eschews the need for dedicated instances entirely, instead relying on keys for identity.
• While a little more on the cryptocurrency side of things, Nostr incorporates direct payments into the network, allowing creators to compensate each other.

This isn’t a proclamation that ActivityPub is inherently bad, so much as these other projects can offer advantages that most existing implementations lack.

There are a lot of big ideas on how to improve the situation, and it boils down to two problem areas:

1. The ActivityPub protocol specification
2. The ecosystem built around ActivityPub.

ActivityPub’s Protocol

The ActivityPub protocol is the heart and soul of most Fediverse platforms these days. As a specification, it stipulates methods and behaviors for implementations to follow. Unfortunately, critics have pointed to the fact that the spec can feel too flexible in defining some behaviors, but too loose in defining others.

“The spec is incomplete,” writes Ilja, a regular contributor to Akkoma, “if someone makes a followers-only post and someone replies, then the ‘Mastodon way’ is to address the reply to the followers of the account who replies. The proper way to handle this, is by addressing the followers collection of the OP, and let OP forward the Activity to its followers. But we don’t do that because we don’t know how to do forwarding.”

Another headache that exists for implementors right now comes from most ActivityPub platforms needing to rely on undefined behavior. The following pieces are heavily relied on, but don’t exist in the spec:

• Webfinger – Webfinger is a common tool and data format for looking up resources at an address. If you’ve ever copied and pasted a URL into search to pull in a remote post, Webfinger is what powers it!
• Privacy Scopes – in standard ActivityPub, servers make use of to and cc fields to determine which people a post gets sent to. These fields can address individual Actors, or a Collection of Actors. However, there isn’t really a specification on how scopes ought to work: Quiet Public, Followers-Only, Private Mention and Local-Only are all examples of privacy scopes that not only define a grouping of people, but also behavior for posts themselves.
• Account Migration – Mastodon kind of set the standard for moving accounts from one server to another: your old profile Authenticates your new one, and a relationship is established. After the primary account is set, the old account gets marked with a Tombstone object that redirects to the new profile.
• Moderation Tooling – federated reports, instance blocks, management of blocklists and permission levels, individual user moderation, etc. This is a rapidly evolving space that depends heavily on collaboration.

However, they’re absolutely required for a working platform to exist in the Fediverse. This leads to implementors to do a lot of extra work to figure out how things work today, and how to correctly use them.

ActivityPub’s Ecosystem

The ecosystem built around ActivityPub suffers from problems, too. Despite aspirations to provide a common protocol between very different kinds of platforms, the Fediverse still predominantly looks and works like Mastodon.

There are three reasons for this:

1. Lack of a Test Suite – ActivityPub was first adopted by Mastodon, which acted as rocket fuel for mass adoption of the standard. However, the lack of an independent testing suite for implementors left builders to instead test against Mastodon, making it a de facto standard.
2. Bespoke Client APIs – In addition to a server-to-server federation protocol, ActivityPub offers a secondary spec for client-server relationship. Mastodon ended up pushing it’s own API that was arguably easier to use, but just about every platform in the space could have instead been a client, instead of building their own stacks, APIs, and federation extensions.
3. Duplication of Effort – A very weird phenomenon in this space is that implementors don’t just build something once. As of this writing, there are approximately six different Group Actor implementations, all of which are built slightly differently, made by different people, and meant to solve different problems.

None of these things are necessarily earth-shattering problems per se, but we’ve ended up with an ecosystem where a lot of effort gets duplicated, people are implementing entire platforms from scratch, and everyone is also using Mastodon as a compatibility benchmark.

Ongoing Efforts

The important thing to remember is that this is far from a hopeless situation. As of this writing, there are some incredibly smart people trying to figure out how to fill in the gaps.

“The most important thing about ActivityPub is that it’s extensible,” says ActivityPub co-author Evan Prodromou, “that’s a strength; it means we can really quickly get new distributed social applications running on the network.”

These groups all intersect in a variety of ways, and each one of them is attempting to attack specific problem areas. They’re constantly comparing notes, holding deep discussions, and investigating what enhancements the whole Fediverse might benefit from.

FediDevs

The Fediverse Developer Network is a newer effort that aims to make development more approachable to implementors and newcomers alike. Their goal? Get people in a room together.

“How do we build this stuff to be compatible with other people’s projects, while also lifting the lowest common denominator for everybody?” says FediDevs founder Johannes Ernst, ” It probably starts with making it easier for developers to find each other and compare notes.”

According to Johannes, FediDevs incorporates three big ideas:

1. Developers in the Fediverse ought to have an easy way to find where everyone else is at, and catch up on what’s happening.
2. New developers need a resource library of best practices, emerging concepts, and documentation to prepare for connecting their apps to a global federated network.
3. There needs to be a place to publish guides and tools that make everyone’s lives easier.

FediDevs has already beared fruit through a project called FediTest, a test suite intended to provide different “test profiles” so that builders can see how their own work might interact with other platforms.

Even though FediTest is still very young, the promise of such an effort is clear: people could stop relying on a specific platform for compatibility testing, and instead use a more flexible, agnostic solution that accounts how lots of different projects do things.

Fediverse Enhancement Proposals

The Fediverse Enhancement Proposals project is a comprehensive effort to distill some of the network’s best ideas into standardized documents that explain how they should work. The effort is an initiative of the SocialHub developer community, and serves as a testbed for their ideas.

FEP is very much in the spirit of XMPP Extension Protocols or Nostr Implementation Possibilities, suggesting ways that existing systems could be extended. Check out some of these ideas:

• FEP-1b12: Group federation – Specifies how a federated group or forum could work. Originally, this was proposed by Nutomic from the Lemmy project, and now Lemmy, Kbin, and Friendica all support this as a standard.
• FEP-5624: Per-object reply control policies – Some centralized platforms have a way to disable comments or replies on a status. What would it take to make this work in a federated model?
• FEP-5feb: Search indexing consent for actors – People on Mastodon can opt-in to being discovered by the Search function. How might we extend this to other Fediverse platforms?
• FEP-c390: Identity Proofs – How might a Fediverse Identity prove its authenticity, while also verifying associated links and accounts?
• FEP-ef61: Portable Objects – How might we separate user data from an instance, so that the user can move it if they need to migrate somewhere else?
• FEP-61cf: The OpenWebAuth Protocol – Derived from the Hubzilla Project’s technology. Wouldn’t it be great if you could use your Fediverse identity across the network? No matter what server URL you land on, permissions can be unlocked for you to perform basic interactions and see private content.

The repository contains a treasure trove of ideas, ranging from immediately obvious needs to larger, more abstract concepts about how the network could work one day. Many of these submissions are still in a DRAFT status for the moment, but a few of the FINAL entries are actively being used. The project is already helping the network develop further.

Social Web Incubator Community Group (SocialCG)

The SocialCG is an implementor’s group that focuses on best practices for those building on ActivityPub. A big focus for the group involves running case studies for different conventions are approached within the Fediverse. Here are a few ongoing studies:

• HTTP Signatures – An examination of how systems like Mastodon use cryptographic signatures as identity proofs on actors and their activities.
• ActivityPub-Webfinger – Studying the how and why so many ActivityPub systems rely on Webfinger to fetch remote data.
• Testing –  A monumental collaboration between dozens of people, this is an ongoing study of existing ActivityPub Testing Suite tools, and insights on how exactly a standard test suite could be built.
• Data Portability – researching existing cases for moving data, activities, objects, and Actors across the network.

Towards ActivityPub 2.0

So, what does all of this add up to? Is it possible to bring all of this work into an updated version of the ActivityPub Protocol standard?

“I think there will be a working group chartered at the W3C to make backwards-compatible changes,” Evan Prodromou explains, “especially clarifying difficult text, and possibly recommending profiles for other standards…”

Despite the importance of the W3C and standardization, though, Evan also believes that there’s value to the fast-paced development of emerging projects with new ideas.

“…the innovation is always going to be at the edge, with new extensions.”

I, for one, agree with him. There’s some amazing developments happening in the space, and the future is looking bright.

 Share