ActivityPub

Chapter 1. Welcome to the Fediverse

I’m so glad that I get to be the person to welcome you to the social web. I’d like to use this opportunity to explain why we’re here, what we’re doing, and maybe where you can fit in. Let’s start with the first steps: understanding social networks.

What Social Networks Do

What is a social network? At its most basic, a network is a collection of objects with distinct connections between them. A railway network, for example, is a set of railway stations connected by train tracks. A computer network is a potentially very big set of computers, connected by wires or electromagnetic waves to one another.

A social network is a group of people and the connections they form with one another. Like computer networks or television networks, information travels along these connections.

People often talk about social networks as the apps and websites that model our social connections and convey information that we send, although that’s probably better thought of as social-network software, social-network services, or just social software. I’ll be using social network to mean either the people or the software interchangeably in this book, but I’ll try to be clear when I mean one or the other.

As of 2024, as I write this book, social-network services have become an integral part of modern society.¹ We use them for our intimate social connections, for our civic and political life, for entertainment, for news. We use them to hold our memories, maintain contact with friends, and share important milestones.

Because social-network services are so ubiquitous, it can be hard to remember that the underlying model is so simple. Many of the most interesting innovations in consumer technology over the last decade have been attached to social networks to take advantage of features like identity and content distribution. Some of my photo-sharing services let me add an animated sticker or a thought balloon to my party photos; the developers who created that feature attached it to a social network to benefit from the distribution.

Other networks let you reuse your identity to make video calls or log in to accounting websites. The identity structure of social networks is so robust that other services can depend on them for registration and login. Figure 1-1 shows the features of a typical social-network platform.

We do a lot with social software, and a lot of websites and apps call themselves social-network services. Here are some of the commonalities:

An identity

In social software, you usually have a unique identity. Sometimes this is explicit, like a unique username or handle. Other times, it’s implicit—even though we never see the identifier, we know that our account is unique.

A profile

The profile is your home base on the social network; it contains information that other people can see about you. It might include your name (or a pseudonym), location, age, hobbies, links to other profiles on other social networks, an avatar picture, a funny or serious self-description, and maybe other profile properties.

Relationships

Social software is social because it supports connections among users. This is how you tell the software and other people on the service about people who matter to you. We make connections with friends, family, colleagues from work, neighbors, celebrities, politicians, or just cool people we met online who we want to keep in touch with. Sometimes these relationships are bidirectional, meaning both people are actively part of the relationship (these are sometimes called friends, although that doesn’t necessarily mean a real-life friend). And sometimes the relationships are unidirectional, meaning one person is interested in the relationship and the other one is mostly unaware of it. These are sometimes called followers/following relationships or fan relationships.

Groups

Along with having relationships with individual people, we can become members of groups. Sometimes everyone knows one another in the group, like a family or a city block; other times the relationship is looser, like all the fans of a TV show, worldwide.

Posts of new content

Whether it’s bookmarks, short texts, long texts, photos, drawings, or videos, social networks let us share things we make with people we know and care about. Sometimes we post a thought that goes out to everyone we know; other times it goes only to a particular person or group.

A home timeline

Social networks often notify you of all the new content from people who you have a relationship with or groups that you’re a member of. That all comes into a single stream of activities that you can read. Sometimes they’re sorted with the newest on top, and sometimes they’re sorted with the most interesting on top. Either way, you can scroll through the feed to see what’s happening in your world right now.

Reactions and replies

When people we know show us something about their lives, we want to tell them or show them that it matters to us. We might comment on a photo they posted, “like” it, or give an emoji reaction. As important as the original content can be, sometimes the reactions and replies are almost as interesting and as good a place to connect.

Reposting

Sometimes a connection posts a question or request that we can’t help with ourselves, but someone we know might be able to. Other times, an image or a video makes a point in a way that we can’t put into words. We want all our connections to see it, and maybe experience the same feeling, and maybe spread their post a little further. By reposting, we can use our network to give content we like a little more attention; the things we repost go out to all our connections in the same way that new things we make do.

Figure 1-1. Wireframes of the web interface of a typical social-network platform, with abstract features highlighted

What Social Networks Don’t Do

People today use social networks so much in their online lives, it can be hard to remember what social networks don’t do. In fact, we’ve gotten so used to the “normal” way that social-network software can work that we have a hard time understanding any limitations. On the major social networks, you can’t always do the following:

Connect with someone on another network

Not all your friends use every new social network. Maybe you want to stay involved with people who haven’t updated to the cool new app you’re using. People sometimes get comfortable in the apps they know and don’t want to jump into a new social network every few months. It would be nice to let your friends stay where they are, but be able to share content from your new app with them, and maybe even see when they respond to it.

See content in your home feed from other networks

On the flip side, when people important to you are developing new ideas or new media on other services, it’d be nice to see that stuff in your preferred home feed (which works just the way you like it) instead of having to download a new app, sign up, agree to terms and conditions, and reconnect to whichever friends are already on the app.

Move your account from one network to another

Many services let you download your files and even some of your connections in a ZIP file. Some ambitious smaller services can even import that ZIP file to a new account. But you can’t rewire your friendships, group memberships, or other relationships to the new account.

Post audio on a photo service

A lot of social-network software is oriented toward a single kind of content: just photo sharing, just videos, just audio, just short text, or just long text. You can sometimes tweak the service to get around these restrictions—for example, by screenshotting a long text and sharing it as an image, or playing music in a video over still images—but the process is usually clumsy and complicated. Often, what matters to us is the community, and our social relationships on the service, and not the particular media type it was started with.

Decide who can see your content and interact with you

All social-network services have privacy policies and security settings, but they tend to be one-size-fits-all. If you have particular needs—like sharing a surprise party invitation with all your friends except the guest of honor—figuring out how to do that can be difficult. And if you’re having problems with a person or a group of people, and you want to prevent them from bothering you and your friends, you have to provide a report to a busy Trust and Safety team, which may not share your priorities and concerns. The team might even delegate these tasks to AI assistants that don’t empathize with personal feelings.

Choose your own business model

All social-network services cost money to run, and eventually all of them look for a way to make money. They may land on subscriptions, premium services, advertising, or a cooperative model. But whatever business model the network service chooses, that’s the one you’re stuck with. You can’t decide you want to pay a subscription and see no ads, or that you’re willing to volunteer to offset your monthly charges. If you don’t like the model, you have to choose between living with how the business works and staying connected to your friends, family, and colleagues, or giving up on the network and getting disconnected.

Make up new ways of interacting with people you care about

Many social-network services are built on a gimmick for how to interact: they might, say, limit the number of characters in a text message to 140 characters or allow only a small number of connections. These constraints can be great incentives for creativity, reflection, and deeper social connection. Given how important they can be, it’s strange that your ability to experiment with different constraints, or expanded abilities, is often deeply curtailed.

Sift, sort, and search data your own way

You may want to find only people in your social network who are interested in dating someone like you. Or you might want to get introduced to a random friend-of-a-friend on a daily basis. You might want your work updates to come before your news, which comes before personal content, which comes before entertainment—or exactly the reverse. Regardless, the business models of many social-network services depend on showing you content in a certain order and hiding other content from you entirely. Using their application programming interfaces (APIs) or data feeds to show things in different ways is usually prohibited by terms of service.

Save your content and community after the service shuts down

One of the most difficult social-network experiences is the service shutdown. Sometimes a venture-capital-funded startup is willing to spend money to get lots of users for a new service, in hopes of later recovering that money as revenue for a future business model. Other times, a major corporation launches the service as an experiment or side project, then trims it to boost share prices. Regardless, when a service shuts down, the entire universe inside that service collapses: all the content disappears, and all the human connections are erased. Even if you manage to get a backup of your personal content, republishing it is difficult, and your connections are gone for good.

All these features leave gaps between our social networks, making them islands on the internet. Sometimes those islands are really big and feel more like continents unto themselves. But they remain isolated and disconnected from one another.

People do what they can to work around this disconnection, of course. Sometimes you’ll see a friend post a screenshot of a different app into their feed, since that’s the only way they can share it. Occasionally you’ll see content captured in a screenshot in one app, posted to another app, and then captured again to be posted to yet another social network!

Some tools let you do a little bit of transferring content between networks. Some networks will use another service’s API to push updates through to the other network, but any feedback (such as replies or likes) from users of that service rarely occurs. On Apple iOS and Android phones, you can “share” a picture from one network to another too.

Locked In to Social Networks

Overall, social-network services can feel really frustrating to a lot of their users, for a thousand reasons. So, the big question is: why don’t they just leave?

One of the awe-inspiring powers of social networks is encoded in a principle called Metcalfe’s law. Bob Metcalfe, cofounder of computer-networking-hardware company 3Com Corporation, observed this property of communications networks in 1983. He noticed that if a network has N nodes, each node can contact N – 1 other nodes, so there are (N × (N – 1)) / 2, or about N² possible connections. Since the value of the network is in its connections, he concluded that the value of a network to its users goes up by the square of the number of users. In other words, big networks are much, much more valuable than small networks, as illustrated in Figure 1-2.

Figure 1-2. A network with 4 nodes has 12 possible connections each way (left); a network with 8 nodes has 56 possible connections (right)—it’s denser, more active, and just more interesting than the smaller network

The value of big networks can have a positive effect; all of us who use the internet or the World Wide Web owe its vast utility to Metcalfe’s law. But it makes it hard for small networks to get started. Users leave the small networks to join the big networks since, by the law, they’re much, much better. Everyone you know is there; everything you want to do is happening there. But users also have a hard time leaving the big networks to go to the small networks. They’re much, much less fun.

Metcalfe’s law explains why users get locked into a network. For those of us who feel frustrated with the social-network services we use, and want to try something new, Metcalfe’s law is what keeps us going back to our old habits.

From Social Network to Social Web

Even if you love the experience of using social-network software, the series of disconnected islands that are our social-network services can be a real source of frustration. So what can you do? The model that some social-network developers have adopted is a federated social network: an alliance of social-network services connected through open standard protocols.

One good way to imagine this is by considering internet email. It doesn’t matter what software you use for reading your email, or even what server your ISP or work organization uses. You can send email to anyone on the internet because your mail server is connected, via a complicated set of open standards, with every other mail server on the planet. Some email addresses aren’t even for people; they could be mailing lists, bots, or other automated tools. The rules on your server don’t matter to anyone else—for example, if your work uses virus scanners on incoming attachments or limits the size of files you can send. The rules your server sets up are right for you and your team, and nobody else gets a say in them.

Now consider the World Wide Web. Hundreds of millions of websites are on the internet today—each with its own menagerie of server software, programming languages, databases, file formats, network structures, APIs, and data feeds. But every one of those sites supports a simple (well, kinda simple) set of standards—like HTTP, HTML5, CSS, and JavaScript—to give users a rich, fascinating experience in the browser. And with links, browser users can move effortlessly between websites without anyone locking them in.

The social web applies the idea of internetworking to the realm of social software. It is a collection of social networks that allows users to make connections across network boundaries. A user on one network can follow a user on a different network and get the same updates in their home feed, as if they were on the same network. On the social web, people can post images, videos, and short and long texts; they can comment, like, and share; they can make jokes, have difficult discussions, and remember what matters most in life. Figure 1-3 shows how a siloed social network works: all clients use a single server, which holds all user accounts. The social web is like Figure 1-4: user accounts are on different servers, clients connect to the server for their user, and servers use an open standard to share information between them.

Figure 1-3. In a siloed social network, client software all connects to a single platform

Figure 1-4. On the social web, individual clients can connect to different servers, and the servers use a backend protocol to connect people across networks

As of this writing, tens of millions of users are on the social web. And because anyone can join, there are tens of thousands of social-network servers—some with hundreds of thousands of users, others with only a single person. Some are commercial ventures; others are run by volunteers; still others are cooperatives or nonprofits. Many of these networks run open source software like Mastodon, WordPress, Pleroma, or Misskey and connect together with open standards.

The social web is an admission that one-size-does-not-fit-all. Every person relates to their social connections differently—with different needs, different processes, different incentives. The diversity of software, both servers and clients, gives people the choices they need to construct their own social experience. Some people are going to find the most popular service, sign up for an account, and use the official client app for their entire time on the social web.² Others will shop around for the right server, the right community, and the right client apps, and then build scripts, connect services, fine-tune, tinker, connect, and generally get their social experience Just So.

The social web is the antidote to Metcalfe’s law. Each of these social-network services is relatively small on its own, which should make them unviable. But, because they interconnect with so many other services around the world, the total number of possible connections is enormous. Your small family social-network service might serve only a handful of people from your household, but by connecting it with the rest of the fediverse, you gain a huge pool of potential friends to talk with.

The social web is sometimes called the fediverse, which is a portmanteau of federated and universe. Federated here refers to the independent services that can become part of the network whenever they choose, as long as they implement the necessary technical standards (more on those in the next section). Nobody can kick you off the fediverse; as long as your social network implements social standards, you’re part of the social web. I use the terms fediverse and social web interchangeably in this book, which may get a little confusing, but I’m sure you’re up for it.

The goal of this book is to teach you how to use the standards of the social web to make cool software and help human beings connect in fascinating ways. You can use social web technologies to connect an existing project to the social web, or you can start something new from scratch. You can make a tool that only a few people will use or something that changes the way people live their lives, online and off.

A Tour of the Standards

Let’s take a quick look at the main relevant standards for social web software: Activity Streams 2.0 for data, the ActivityPub API for client-to-server programming, and the ActivityPub federation protocol for server interconnection. (Don’t worry; they all get their own deep dives in later chapters.)

Activity Streams 2.0

Activity Streams 2.0 (AS2) is the data format for the social web. It’s the common language that all fediverse software speaks: a standard JavaScript Object Notation (JSON) format for encoding information about common social-network entities.

AS2 was designed to allow the maximum expressiveness possible, so you can take content, actors, and experiences from the many kinds of social-network services and share them across service boundaries.

AS2’s data types include the following:

Actors

People, groups, organizations, services, and applications. The active parts of a social network; those who act. Unrelated to Hollywood celebrities!

Objects

Files like images, video, and audio; short and long texts; albums and lists. These are the stuff of websites and apps: the things we make, share, and do. More abstract types also exist, like places, relationships, events, and questions.

Activities

AS2 has activity types for creating, reading, updating, and deleting objects—the CRUD necessary for making and maintaining files. It also includes activity types for reacting to others’ work by liking or sharing it and for forming and changing the social graph by following people and joining groups.

In the language of the social web, an activity works like a sentence. An activity says that someone (the actor) did something (the activity) to something else (the object). Sharing activities is the most important part of connecting on the social web.

Each of the AS2 data types has dozens of properties that can be used to describe it: names, IDs, summaries, images, latitudes and longitudes and altitudes, heights and widths. The format is extremely flexible; you can include as much or as little property information about an object as you want. This flexibility lets us use the format for tons of applications. It can be a little harrowing getting AS2 data on the wire; you never know if you’re going to get a big, bushy tree of data or a minimal, terse little packet. But once you get used to the format, you can appreciate the power this flexibility brings.

Almost as important, AS2 is extensible. If you come up with new kinds of content or activities or properties of things that were never dreamed of by the standards group that made AS2, you can define it and include it in your existing AS2 objects.

A lot more details about AS2 are in Chapter 2 and throughout the book. The appendices have detailed reference information on all the types and properties defined in the standard. It’s really the glue that holds the social web together.

The ActivityPub API

The ActivityPub API is the mechanism for connecting web and mobile client software to ActivityPub servers. It’s the entryway for humans to interact with the social web.

The ActivityPub API is a standardized API. Different servers provide the same interface; clients can use that interface on each service without knowing which service they’re talking to. This is an unusual setup in the world of APIs; although some well-known and interesting patterns exist, like REST or GraphQL, not many fully standardized APIs are available.

As I’ve mentioned, all the interesting objects in the network have their own URLs that provide an AS2 representation of the object. This includes a number of interesting feeds, like an actor’s outbox (a feed of all their activities) and inbox (a feed of all the activities of all the people they follow), and their social graph (people, apps, groups, and services they are connected to).

Client software can also use the API to create and share new activities. The primary mechanism for interacting with the entire fediverse is through the ActivityPub API, posting new activities to a particular endpoint.

The ActivityPub API specification defines what happens when each kind of activity is sent to the server—Create, Like, Announce, Delete, and so on. The server is responsible for implementing them and distributing them.

The ActivityPub API is extensible because the AS2 format is extensible. Developers interested in collaborating can define different kinds of objects, activities, and properties, and even different kinds of feeds.

One interesting part of the ActivityPub API is that you don’t have to think about federation when you use it. That’s all handled by the server software; as far as the client software is concerned, it’s all one big network. In fact, the advantages of a standard social-network API are still pretty valuable. I’ll cover the ActivityPub API in excruciating detail in Chapter 3. It’s one of my favorite parts of the social web standard suite, and I hope you’ll find it as mysterious and powerful as I do.

The ActivityPub Protocol

The ActivityPub protocol is the main tool for moving data across the social web. Chapter 4 covers the ActivityPub protocol in all its glory, so this is just a brief introduction. The protocol uses a similar mechanism to the ActivityPub API, but instead of transferring activities from the client to the server, it is a server-to-server protocol that allows one social network to send data to one or more other social networks, standardized by the World Wide Web Consortium (W3C), the standards body that manages specifications for many parts of the web stack. These internetwork connections are what allow the social web to grow.

If you’re familiar with how internet email works, you can think of the ActivityPub federation protocol as the Simple Mail Transfer Protocol (SMTP) happening between email servers and the ActivityPub API as the Internet Message Access Protocol (IMAP) happening between the client and its own server. This analogy isn’t perfect, but it points you in the right direction.

The ActivityPub protocol defines a set of important patterns that servers need to follow if they want to connect. Every object that they have on their service needs to be available through a web URL in the AS2 format. People, images, groups, replies—the whole thing is on the web.

The protocol defines a mechanism for delivering activities from one service to another. It also says what should happen when a service receives different kinds of activities: a Follow activity should make a connection between two actors. A Like activity should increase the number of likes on a video. Each activity does something different.

Distribution is a big part of the ActivityPub protocol. As an actor does various activities, those AS2 objects get distributed to everyone the actor wants to see them—often, all their followers. With social-network accounts that have tens of thousands, hundreds of thousands, or even millions of followers, distributing activities efficiently becomes a big deal.

If this sounds a lot like the ActivityPub API, well, that’s no accident. The two halves of the ActivityPub specification were designed to work together seamlessly, so the structure, data formats, and interaction model are very much aligned.

I might sound like a broken record at this point, but because AS2 is extensible, so is the ActivityPub protocol. You can define new kinds of activities, and other services on the network that implement the extension can receive and apply those activities.

Together, these three standards form the skeleton of the social web. They connect client software with server software, and server software with other server software—all speaking a common language to describe social objects and interactions.

Of course, AS2 and ActivityPub are built on and interact with other standards: JSON and JSON-LD for data-transfer encoding; WebFinger for identity; OAuth 2.0 and HTTP Signatures for security; HTML for formatted content; a half dozen image, audio, and video file formats; and HTTPS to connect it all together. I’ll explain each of these building blocks as they come up in the following chapters. The social web isn’t separate from the World Wide Web; it’s deeply integrated.

A Brief History of the Fediverse

The standards for the social web did not arise out of a vacuum. They came from patterns, specifications, and products that have been important since the beginning of the internet. Knowing these precedents can help you understand how and why the ActivityPub standard works the way it does, but this knowledge is not required, so feel free to skip this section if you just want to get to the coding part.

The federation pattern dates back to the origin of the internet. I mean, hey, internetwork is right there in the name. The internet started as a computer network crossing organizational boundaries between universities, corporations, and government institutions. Each of these organizations maintained a level of authority within its own network but used open standards to maintain the connections with others. This allowed cool applications, like email, to be built on top of the internet.

The World Wide Web was first launched in 1990 by Tim Berners-Lee at the European Organization for Nuclear Research (CERN) in Switzerland. Like other internet technology, it uses a federated structure: each domain has its own, perhaps very large, structure of documents housed there, managed and controlled by the domain’s owner. The web also defines a uniform protocol for exchanging documents, HTTP, and a relatively small set of standard document formats for text, images, video, and audio, plus styling instructions and executable code. By depending on this constrained set of formats, the web allows an explosive amount of client and server software, and even machine-to-machine conversations via web APIs.

As the web grew, websites began updating more frequently than users could keep up with. Netscape Corporation, a major browser vendor, developed a standard for updated content on a website. Really Simple Syndication, or RSS, was picked up by the W3C and, separately, the legendary Dave Winer of Userland Software. With the addition of the related Atom feed format later in the 2000s, developers had multiple ways to convey update feeds across the internet.

This was great, because at the same time blogging was exploding as a phenomenon. A blog is a sequential website that displays posts in reverse-chronological order (newest first). Winer calls a blog “the unedited voice of a person” and emphasizes its personal expression as well as technical features. As the 2000s progressed, anyone could set up a blog to share their thoughts, experiences, jokes, code, problems, and ideas with the world. Blogs worked really well with RSS feeds; each blog post was an entry in the feed. Instead of loading up each of your friends’ blogs every day, you could use specialized software called an RSS feed reader to bring them all together in one place.

Social graph software first arose in the 1990s with services like SixDegrees, which let people define their friend and family relationships and do interesting analysis on the graphs. But in the mid-2000s, new social-network sites like Friendster, MySpace, Twitter, and Facebook arose that combined the social graph, the blog authoring experience, and the feed-reading experience into one service. This proved exceedingly popular; thousands of these services launched between 2005 and 2010.

The social-network services soon branched out to become social-network platforms. They built APIs, data feeds, and embedding mechanisms that let developers from other companies embed widgets onto a user’s profile page or inject active applications into their home feeds. It was an interesting, fertile time on social networks!

Almost as soon as social-network services brought the large public populations together on one service, private social-network services started setting up barriers between them. A typical usage was for a single company—an enterprise social network—to allow employees to post, comment, share, and follow other staff, but not people outside the network. Millions of enterprise social networks were launched.

Meanwhile, back in the standards world, a new federated standard called Jabber (later, Extensible Messaging and Presence Protocol, or XMPP) was developed by Jeremie Miller to connect chat messaging systems. It defined a structure for a client-to-server interface, a server-to-server interface, and a common extensible data structure. With dozens of server and client implementations and large messaging service support, XMPP provided a great model for how a federated software ecosystem could work.

So, that’s a lot of threads; let’s try to bring them all back together. Numerous people started open source social-network services toward the end of the 2000s, with varying levels of success. I started one called identi.ca, running software that I created (called StatusNet at the time and now called GNU Social). Similar services and projects began, such as Elgg, Diaspora*, OneSocialWeb, tent.io, Appleseed, DiSo, Buddycloud, Friendica, and many others, often with their own social protocols that didn’t interoperate.

A series of informal Federated Social Web Summits in the early 2010s brought social web developers together to share patterns and ideas. The developer community started to coalesce around a group of interesting, interrelated technologies: OpenID, OAuth, PubSubHubbub, Activity Streams (an early version, based on Atom), Salmon, and WebFinger. My team at StatusNet assembled these into a protocol stack we called OStatus, although others call it “the DiSo stack,” after a federated social web project started by Chris Messina and Steve Ivy. We also used Activity Streams Atom on top of the Atom Publication Protocol (AtomPub) to implement a robust client API. A brief peak for this period in the federated social web was interoperability between StatusNet, Google’s social-network product Buzz, Diaspora*, Tumblr, and others.

OStatus had its benefits but also problems. Most notably, it did not have an effective mechanism for privately distributing content. Everything posted on the network was public. Although this was common at the time, borrowed from the public nature of the blogging network, it inhibited uptake of the technology. People were used to having more fine-grained privacy control in commercial social-network services.

In 2013, a more traditional industry group of enterprise and consumer social-network companies formed OpenSocial, a standards organization for social-network platforms. Although OpenSocial did not define a federation protocol, it did important foundational work in defining standard APIs, so an application or widget developed for one social-network platform could be easily ported to another.

The early 2010s were a nuclear winter for social-network standards. Although some important work was happening, Metcalfe’s law and brutal competition winnowed down the massive number of consumer social networks launched in the late 2000s to a few dozen by the middle of the 2010s. As enterprise chat systems like Slack grew, the enterprise social-network market also dried up. With fewer independent social networks, and a few dominant networks with close to a billion users apiece, social-network interoperability seemed like an unnecessary evolutionary dead end.

In this harsh environment, my company StatusNet closed. I hunkered down and wrote a new social software platform called pump.io, including a new federation protocol, using research funds from the Canadian and Quebec government. Unlike OStatus, pump.io used a unified model across all parts of the stack, which made it much easier to work with. In particular, it used Activity Streams’ new JSON format, which made it much more like the popular APIs of the time. The seams joined more easily.

In 2014, the OpenSocial organization folded and turned over all its specifications and other assets to the W3C. Spurred on by this development, the W3C chartered a working group to build a stack of social-network standards: a social data standard, a social API, and optionally a social-network federation protocol.

I cochaired the working group with Tantek Çelik and Arnaud Le Hors. The Social Web Working Group (SocialWG) worked for a grueling three years and eventually published a number of social-network standards—not all compatible. The stack that inspired this book was based on a revision of Activity Streams, which was edited by James Snell and me and published in mid-2017. The API and protocol were based on Erin Shepherd’s adaptation of the pump.io API and protocol to AS2. Called ActivityPub, the spec was edited by Christine Webber-Lemmer and Jessica Tallon, was further refined by Amy Guy, and published in early 2018.

In 2016, meanwhile, Eugen “Gargron” Rochko launched the Mastodon project. A federated open source social-network server, Mastodon originally connected via the good old OStatus protocol to instances of GNU Social and others. When ActivityPub launched, though, the Mastodon team pivoted and adopted the protocol, giving it a first key set of users.

A Tour of the Fediverse Today

Whew! Now that that’s over, here we are in the present. As of mid-2024, somewhere around 20 million people have accounts on services on the fediverse. Mastodon remains the most popular software, with some of the most advanced social features, and leads the way in extending the ActivityPub protocol for new uses. A dedicated nonprofit headed by Rochko directs donations into software development and network operations for the big social network, mastodon.social, run by the service. In a big way, the social web depends a lot on interoperability with Mastodon.

Meanwhile, an explosion of social networks has joined the service—around 25,000 services as of this writing. Some are run by companies for their employees, and others are run by individuals for their family and friends, or just for themselves. But many, seemingly the vast majority, are run by individuals or small groups as a public service for general users. Often these servers bring together groups by social or professional affinities—geographically associated services, professional services, or services for women or for LGBTQ+ communities. Some are incorporated as nonprofits or even as member-owned cooperatives. My home service, cosocial.ca, is a member-owned cooperative for Canadians.

Other server software competes with Mastodon for hosting social services. Friendica remains popular, and Pleroma is a great service with low resource requirements. Bonfire, Wildebeest, Takahē, and Misskey provide microblogging-like interfaces with various alternate implementation decisions.

But the types of services available on the fediverse vary widely too. Pixelfed, for example, is a social service focused on photo sharing. PeerTube provides a social video platform. Lemmy and Kbin provide social news interfaces, and BookWyrm is a social book review service. WriteFreely, on the other hand, lets you write long, blog-length text—much more expressive than the limited microblogging on other platforms.

Meanwhile, we see adaptation of more traditional “social” software to the social web. WordPress, the blogging software that powers more than 40% of the domains on the web, has an ActivityPub plug-in that lets WordPress users publish into the social web. Discourse, a forum platform, also lets users link into the fediverse.

With so many communities and so many software platforms, the fediverse has a Wild West vibe to its culture (although it’s hard to generalize a community of tens of millions of people). Many of the people on the network have sought a place to establish their own values and to exercise a level of autonomy they can’t on other networks. LGBTQ+ people, open source and open standards enthusiasts, and general technology fans seem to find themselves comfortable on the network.

But from my account on cosocial.ca, I follow feeds from the British Broadcasting Corporation (BBC) (on its own dedicated service) and politicians in the United States and Canada. Web information aggregators like Techmeme publish into the network, plus entertainers like George Takei and Morgan Fairchild.

The pace of change over the last few years has been intense. Changes of ownership at commercial social networks, with consequent changes of policy, have put many communities adrift, trying to find a new home. Some have landed on the fediverse. Other incentives have been changes to antitrust and privacy regulations in Europe and the US, which make island-like social-network services less and less tenable.

The influx of new users hasn’t always been without controversy. The number of people with accounts on the network has jumped almost tenfold during this time, and many of the old-timers who have been around since 2016 feel like their turf has been invaded. Will the unique culture they’ve created be spoiled by incoming crowds and newly connected services? Or will the higher level of control that federation brings them let them maintain their own culture with their own rules? Only time will tell.

What the Fediverse Holds in Store for Tomorrow

As I write this, the fediverse is in a time of rapid growth, and we are poised for even more. Announcements from the Mozilla Corporation in December 2022 and Meta in July 2023 that they will be bringing new networks to the social web mean, potentially, another 100 million people or more joining the network, almost overnight. With that many users, and big social players, the fediverse will be attracting more services and more client developers. Another period of tenfold growth is not an unreasonable prediction.

As this next period of the fediverse begins, it’s impossible to say exactly what will happen. One possibility is that Mastodon, the current 600-pound gorilla of the fediverse, will cede its status as the dominant platform on the network. Having more participants with equal levels of power might require more collaboration among developers.

Another possibility is that other social-network services, with new gimmicks and parameters, will join the network. They’ll bring their own sets of expected behaviors, which might require extensions to the ActivityPub and AS2 standards.

Other services will likely also join the fediverse—or, rather, provide new kinds of interactions that aren’t available yet. Network-wide search, for example, has proved an elusive goal on a social web, where many users value their privacy more highly than convenience. Onboarding services that help find your contacts spread across the fediverse can provide more help for new users. And social analytics, services that help you understand your own social graph, can grow as big business, influencers, and other brands will want to measure their success on the fediverse.

Potentially, expansion could reach domains that we don’t normally think of as social software. For example, many game consoles include a social platform where players can form connections. Each user has a feed of their activities on the platform—games they’ve played, scores they’ve reached, and in-game achievements they’ve attained—which is shared to each connected player. Could these game networks connect into the fediverse, letting users on other social services follow play? Could they even federate across console platforms?

Another domain is the Internet of Things (IoT), the network of connected smart appliances found in homes and businesses. These smart devices with embedded microcontrollers can report sensor readings to home hubs or mobile phone apps, but they’re hampered by a lack of appropriate standards with broad enough usage. Could this broadcast mechanism, with custom AS2 activities representing sensor readings or device controls, work over the social web?

Once we start talking about devices reporting to people and responding to commands, we can go into areas like enterprise applications or even process control. Can manufacturing systems report the number of products they’ve created in the last hour to whomever needs to hear it? Could you follow a package on the social network as it moves across the country? Loosely coupling the emitters of data to the consumers of that data, through a publish/subscribe network, is exactly how ActivityPub works. And it might be just what the doctor ordered for enterprise integration.

This is all just speculation on my part, of course. Chapter 6 covers future directions for the fediverse in more depth.

Honestly, social networking is a big enough domain to take on. I love social-network software, and I love the absolutely broad universe of features and apps that software developers have made to connect people. When it comes down to it, our connections to the people we love, our friends, our classmates, our family, our colleagues, and our neighbors are the most meaningful things in life. Making these relationships better, richer, stronger, and more rewarding is the most important use of computer software, by far.

What does the future of the fediverse hold? That’s not really up to me, author of this book and dabbler in software and standards. Systems like the social web become truly amazing when developers build software that the system creators never imagined. I hope this book can help you bring your ideas for new fediverse software to fruition. I can’t wait to see what you build.

Conclusion

As you can see, ActivityPub has deep roots. However, there’s no better time than right now to learn the protocol and understand the ecosystem. The basic architecture—a data format, API, and federation protocol—is easy to understand at a high level. In the following chapters, we’ll do a deep dive into each one so that you can be part of creating the future of the social web.

¹ Future humans: if this is no longer the case in your time, thank you for reading this historical text.

² Looking at you, mastodon.social users.