What is ActivityPub, and how will it change the internet?

Colorful game pieces connected by lines

A new kind of social network

There’s a new social network in town. It’s called Mastodon. You might have even heard of it. On the surface, Mastodon feels a lot like Twitter: you post “toots” up to 500 characters; you follow other users who say interesting things; you can favorite a toot or re-post it to your own followers. But Mastodon is different from Twitter in some fundamental ways. It offers many more ways for users to control the posts they see. It fosters awareness of the effect your posts have on others through a content warning system and encourages accessibility with captioned images. At its core, though, there’s a more fundamental difference from existing social networks: Mastodon isn’t controlled by a single corporation. Anyone can operate a Mastodon server, and users on any server can interact with users on any other Mastodon server.

This decentralized model is called federation. Email is a good analogy here: I can have a Gmail account and you can have an Outlook account, but we can still send mail to each other. In the same way, I can have an account on mastodon.technology, and you can have an account on mastodon.social, but we can still follow each other, like and re-post each other’s toots, and @mention each other. Just like Gmail servers know how to talk to Outlook servers, Mastodon servers know how to talk to other Mastodon servers (if you hear people talking about a Mastodon “instance”, they mean server). And just like Gmail and Outlook are controlled by different corporations, Mastodon servers are owned and operated by many different people and organizations. If you wanted, you could host your own Mastodon instance!

Why does this matter? It means that Mastodon users have choice about where they hang out online. If Twitter decides that your posts shouldn’t be on their platform, they can shut down your account and there’s nothing you can do about it (or conversely, if they decide your f-ed up content is totally fine, there’s nothing anyone else can do about it). On the other hand, if you disagree with the administrators of your Mastodon instance, you have the choice to move your account to another instance (switching providers, as it were) or to host your own instance if you’re willing to dedicate the time and effort.

The federated model also tends to align incentives better than centralized alternatives. Mastodon instances are usually run and moderated by members of the community that uses that particular Mastodon server – for example, I’m part of a community of tech folks over at mastodon.technology, and our server is administrated and moderated by a member of the community. He has a vested interest in making mastodon.technology a nice place to hang out since he hangs out there too. Contrast that with Twitter: Twitter is owned and operated by a massive, venture-backed, for-profit corporation. Now, I’m certainly not against companies making money (more on that later), but Twitter only cares about making Twitter a nice place to hang out to the extent that they profit by it, which has led them to make some user-unfriendly choices.

So Mastodon is pretty cool. But that’s not what really gets me excited. I’m excited about how Mastodon servers allow users on different instances to interact. It’s a protocol called ActivityPub, and it’s going to change the way the internet works.


ActivityPub is a social networking protocol. Think of it as a language that describes social networks: the nouns are users and posts, and the verbs are like, follow, share, create… ActivityPub gives applications a shared vocabulary that they can use to communicate with each other. If a server implements ActivityPub, it can publish posts that any other server that implements ActivityPub knows how to share, like and reply to. It can also share, like, or reply to posts from other servers that speak ActivityPub on behalf of its users.

This is how Mastodon instances let users interact with users on other instances: because every Mastodon instance implements ActivityPub, one instance knows how to interpret a post published from another instance, how to like a post from another instance, how to follow a user from another instance, etc.

ActivityPub is much bigger than just Mastodon, though. It’s a language that any application can implement. For example, there’s a YouTube clone called PeerTube that also implements ActivityPub. Because it speaks the same language as Mastodon, a Mastodon user can follow a PeerTube user. If the PeerTube user posts a new video, it will show up in the Mastodon user’s feed. The Mastodon user can comment on the PeerTube video directly from Mastodon. Think about that for a second. Any app that implements ActivityPub becomes part of a massive social network, one that conserves user choice and tears down walled gardens. Imagine if you could log into Facebook and see posts from your friends on Instagram and Twitter, without needing an Instagram or Twitter account.

So here’s how ActivityPub is going to change the internet:

No more walled gardens

ActivityPub separates content from platform. Posts from one platform propagate to other platforms, and users don’t need to make separate accounts on every platform that they want to use. This has an additional benefit: since your ActivityPub identity (your Mastodon account, your PeerTube account, etc.) is valid across all ActivityPub-compliant applications, it serves as a much stronger identity signal, preventing malicious actors from impersonating you (e.g. creating a Twitter account in your name). If you can share one account across multiple platforms, no one can pretend to be you on those platforms – you are already there!

Social networking comes built-in

With traditional internet media, you need to rely on external services to share your work on social networks. If you want people to share your YouTube video around, you need to post it to Facebook or Twitter. But ActvityPub-enabled applications are social by nature. A PeerTube video can be shared or liked by default by users on Mastodon. A Plume blogger can build an audience on Mastodon or PeerTube without any additional effort since Mastodon and PeerTube users can follow Plume blogs natively. Users on all these platforms see content from the other apps on the platform of their choice. And Mastodon, PeerTube, and Plume are just the beginning – as more platforms begin implementing ActivityPub, the federated network grows exponentially.

Network effects that help users instead of harming them

“Network effects” leaves kind of a dirty taste in my mouth. It’s usually used as a euphemism for “vendor lock-in”; the reason that Facebook became such a giant was that everyone needed to be on Facebook to participate in Facebook’s network. However, ActivityPub flips this equation on its head. As more platforms become ActivityPub compliant, it becomes more valuable for platforms implement ActivityPub: more apps means more users on the federated network, more posts to read and share, and more choice for users. This network effect discourages vendor lock-in. In the end, the users win.

It’s going to be an uphill battle

I hope I’ve convinced you of the radical impact that ActivityPub could have on the internet. But there are some significant barriers preventing widespread adoption. The thorniest one is money.

Why is money an issue? Aren’t Mastodon and PeerTube free and open-source? Well, first of all, open source projects need funding too (that’s a big topic that deserves its own blog post, so I’m leaving it alone for now). The bigger issue right now is user adoption. The ActivityPub network is only viable if people use it, and to compete in any significant way with Facebook and Twitter we need a lot of people to use it. To compete with the big guys, we need big money. We need to be able to spread the word through marketing and blogging, to engineer new ActivityPub applications, and to support people working full-time on bringing about this revolution.

I know this isn’t necessarily a popular view in the open-source world, but I see funding as a critical priority to bring about the vision that ActivityPub promises. Unfortunately, it’s not clear how to obtain it.

All the major ActivityPub-compliant applications I’ve written about are open source projects, built and run by volunteers with tiny budgets. Traditional social networking companies like Twitter and Facebook are funded by selling advertisements on their platform. But in order to make any significant revenue from ads, you need a centralized audience whose attention you control. Facebook needs to be able to say, “we have X billion users; give us your money and we will show them your ads”. Plus, the big social companies extract value from their users by segmenting them based on their behavior and interests, enabling micro-targeted ad campaigns.

None of that is possible when the users and content are spread across many servers and platforms. There is no centralized audience to segment and advertise to. We’ll need to rethink the fundamental business model of social networking if we want ActivityPub to take off.

That being said, I do think ActivityPub offers tremendous business value. It turns your corporate blog into a social network by offering native sharing, following, liking, and replying. And it does so on your customer’s terms, which not only prevents abusive, spammy content but also helps your company’s reputation with users and potential customers. These benefits are valuable, and I think there is a way to turn that value into funding.

It’s important to think about how to make this revolution happen. ActivityPub has the potential to change the way we think and act on the internet, in a way that encourages decentralization and puts users first again. That’s a vision worth fighting for.

23 thoughts on “What is ActivityPub, and how will it change the internet?

  1. I feel like there’s a bit of a “one size fits all” thinking here which loses sight of how the Internet is more than short status updates. While ActivityPub is a great model for sharing things that are In The Now, the uniform experience doesn’t really work all that great for a lot of kinds of content. Where you see the “post a video on PeerTube and have others comment on Mastodon” as a positive I am not so sure that providing a homogenous UX around heterogenous data is a good idea.

    A couple months ago I wrote https://beesbuzz.biz/blog/2535-ActivityPub-hot-take and while my thinking has drifted a little bit since then I still feel like there’s plenty of room for multiple subscription/notification protocols, and in particular long-form content, or content with a specific UX (such as games or nonlinear/hypertext/infinite-canvas/long-form comics/etc. content), much more benefits from living in its own little arena.

    Having better integration such that you can use an ActivityPub-based account for authentication on the third-party site (for access control or in-context commenting/interaction/etc.) is undeniably a good thing, but that’s where I feel like OpenID would have been nice if it’d actually caught on.

    I guess ActivityPub at least provides a much more likely standard OAuth-type API that could be used in OpenID’s place, but there’s something that still feels intensely dissatisfying about that situation to me.

    1. I read through your blog post, and I thought you made some good points. In particular, I hadn’t thought about the waste associated with content being persisted on multiple servers as it propagates across the network.

      I am not so sure that providing a homogenous UX around heterogenous data is a good idea

      I would argue that ActivityPub actually provides the opposite – it gives a heterogenous UI to homogenous data. The content itself is well-defined by the ActivityPub specification and is the same shape no matter what particular application you are on. The UX, on the other hand, is determined by the implementation, which means users get to pick the experience that they prefer to interact with the content.

      games or nonlinear/hypertext/infinite-canvas/long-form comics/etc. content

      I agree that these types of content aren’t a good fit for ActivityPub. They also don’t really benefit from federation in the same way that blog posts, social content, etc. does. But that doesn’t mean we wouldn’t benefit from standardizing the underlying protocol of social networks and blogs.

      I guess at the end of the day I think that having one standard protocol for doing social network stuff is better than having many competing protocols, since a standard approach maximizes interoperability. And I think that ActivityPub meets that need better than RSS (I’ve never looked into Atom, so I can’t comment on how it would fit).

      1. But the data isn’t homogenous, and the UX is generally not all that heterogenous. All of the UX implementations so far are in the form of one or more timelines that show content based on a purely chronological basis, and the only content filtering is in the form of hashtags within the content itself (i.e. no metadata tags for filtering and so on). Anything that doesn’t fit itself very well to the timeline view is presented in the form of a link that goes to another site with its own UX, divorced from all interaction.

        Atom is more or less an extension of RSS (conceptually, although the DTD is totally different), but it provides a couple of very helpful things that RSS doesn’t. Most of them are in the form of extensions (via XML namespaces) which allow incremental support for things like archive feeds, reblogs/conversations/references, enclosures (which were hacked into RSS), and FOAF (i.e. social discovery stuff, sadly now abandoned).

        I feel like the ActivityPub use case has assumed that the data is homogenous and that the heterogenous access to it is okay, but it’s more like a “lowest common denominator” situation at this point where that situation is focusing so much on replicating Twitter and Facebook and not, like, the entire rest of the web where people can be incredibly expressive in ways which simply do not fit within a timeline.. I hope to see the protocol get extended further but there will have to be a lot more thought put into the UX to make it sensible in the context where it’s being developed at this point.

        I feel like adding push onto Atom (which is also a thing! PubSubHubBub was the original basis of OStatus!) would have been a better choice than throwing out the entire rich ecosystem of Atom in order to support a smaller use case.

        1. All of the UX implementations so far are in the form of one or more timelines that show content based on a purely chronological basis, and the only content filtering is in the form of hashtags within the content itself

          Not quite. PeerTube has a Youtube-like UI where videos are displayed in a grid based on an algorithm (I think based on popularity, but I’m not sure). This is actually a pretty good example of my point: when you view a PeerTube account through the PeerTube UI you get a grid of videos, whereas if you view the same account through the Mastodon UI you get a chronological timeline.

          Anything that doesn’t fit itself very well to the timeline view is presented in the form of a link that goes to another site with its own UX, divorced from all interaction

          This is true, and it’s a bad default experience. On some level, though, all syndication protocols face this problem – how do we take content that was meant for one context and display it in another? I think it’s possible for different ActivityPub applications to answer this differently, e.g. Mastodon displays text that links out to the real content while another app could put the content in an <iframe>.

          But I definitely agree that the protocol will need to be extended, and the UX of ActivityPub apps considered carefully, for ActivityPub to really become a viable way to distribute web content.

          1. Interesting. So what does it look like when a PeerTube user subscribes to a Mastodon user?

            Atom and RSS both leave the presentation up to the client, and clients typically go with something either like an email inbox or a stream of updates or something in between. Personally I use FeedOnFeeds set to default to a stream of unread content from oldest to newest, and sometimes filter it by a single source.

            The actual data provided in atom feeds simply declares its content-type and any attached media in the form of URLs. Realistically the content-type is almost always text/html and media attachments are usually audio (which most clients present with an embedded player), or rarely images (which are presented with a link). The reader typically also sanitizes the HTML, with various rules for whitelisting iframes (typically YouTube or SoundCloud embeds) and specific allowed inline CSS. And then both the feeds and the readers make it very obvious and easy how to get back to the original item to see it in its native habitat.

            Granted, the UX is very inconsistent and usually comes down to the preferences of whomever designed the feed itself. Lots of comics only show an excerpt, for example, and lots of blogs only show above-the-cut content. I’ve done a lot of iteration on my own feeds to try to put as much as possible into the client’s control while capitulating to the reality that many clients simply suck. Like,most don’t actually support atom’s built-in concept of a comments link, so I put one in a footer in the content tag as well, for example.

            Plenty of feeds also don’t provide UUIDs or item dates or the like and it’s up to clients to try to interpolate those. Dealing with that has been some of the most annoying work on FeedOnFeeds to do, incidentally. But that’s mostly an RSS issue; atom actually requires those elements (but many comic CMSes do a minimum-effort barely-validating RSS feed).

            So I’m not claiming Atom has all the answers here. I have been thinking a lot about making a smarter successor to a FeedOnFeeds which really tries to take advantage of Atom though (such as handling tag filters and archive feeds), with the hope that more content providers would see the light about properly supporting Atom.

            Oh, but to circle back around, flrig.beesbuzz.biz is an example of a site-specific atom client that takes advantage of atom features (such as license declarations) and does things in ways which are really easy in atom but would be painful in ActivityPub. 🙂

            1. When you visit a Mastodon user’s page in PeerTube, e.g. https://peertube.video/accounts/jdormit@mastodon.technology/videos, it just shows up as a profile page with no videos. That’s a choice by the PeerTube developers, though – if they wanted to display the Mastodon user’s posts they could.

              I would love to see a future where there is more UI interoperability between ActivityPub clients.

              Not to mention authentication, which I think is the really difficult consideration for client interoperability – there’s no standard, so it’s hard to make clients that let users post to more than one ActivityPub service with the same identity (i.e. posting PeerTube videos and Mastodon toots from the same ActivityPub Actor).

              1. Based on this I’m still not seeing what ActivityPub brings to the table that Atom + PubSubHubBub don’t, but maybe that’s just my lack of imagination. 🙂

  2. Unless ActivityPub also formalizes the project to transfer ones identity from one host to another, it falls into the same traps of what it’s trying to replace.

    Unless the lock-in of network effects can be countered, users still lose out and are still at the mercy of whatever instance they first sign up with.

    1. ActivityPub as a protocol doesn’t have any defined way to, say, forward messages from one Actor‘s host to another, but it doesn’t prevent implementations from doing that either. For example, Mastodon has a pretty good host-switching mechanism where you can set a flag that forwards your old account to your new one. I’m not actually sure how much data gets transferred over, though…

      In any case, I agree that it would be good to have this in the spec. I think the whole story around identity is a little weak and could stand to get fleshed out.

      1. As I understand it, no actual data gets transferred; it just broadcasts a message to followers saying “hey this account has moved, want to follow the new one?” (more or less) and there’s a simple forwarding UI on the profile. It’s up to the user to migrate their follow/block/mute lists, and up to followers to decide to, er, follow them, and no status updates get transferred at all.

        Due to the nature of Mastodon it’s probably okay for older status posts to get lost to the ether anyway (what with everything being in-the-now and whatever), and any mechanism for automatically transferring data needs to be guarded against obvious attacks like “wait this isn’t really me” or “the user decided to inject fabricated data into a stream of ‘migrated’ content” and fabricated data can be anything like retro-posted stuff or things fabricated to look bad (which is already a concern on Mastodon since nothing stops people from manually populating stuff into their own instance tables, of course).

        At a certain point we kind of have to let go of the permanence of Internet content as a concept.

        Identity migration would definitely be a good thing though; one of the places where I’m actually interested in integrating ActivityPub into Publ is that it makes for a much stronger user story for friends-only/private content than what I have right now, and while all of the protocol-level pieces are in place it’ll be very important to be able to trust your authorized readers list without having to manually manage every change to it. But that feels like a problem that can be handled as the network grows, rather than something that must be solved right away.

        Another way of looking at it: people used to change email addresses all the time and that didn’t cause email to get thrown out.

  3. I think you are providing the directions for cooking a (free range, organic, not genetically modified, …) stew. And you hope that people will pick it above any other item on the menu.

  4. Since I played a major part in bringing IMAP to every desktop and electronic device on the planet, it’s only appropriate to reference this:


    Now what’s the difference between ActivityPub and Zot6? Pretty much the same things.

    Osada will be better than Mastodon
    and zap is still a mistery but very promising


  5. While on the subject of authentication, I think that this issue could very much be solved by the use of IndieAuth; imagine combining both ActivityPub and IndieAuth? Wouldn’t necessarily solve the nomadic identity issue that Hubzilla does, but would give a trusted identity that folks could use.

  6. The massive over-centralization and concentration of power that corporate social networks have obtained is a serious threat to democracy (aka brexit and trump) but I have a more basic problem with them. I don’t believe social networks should be maintained by businesses. It doesn’t make any sense. They are community services like parks, libraries and theaters, they shouldn’t be expected to generate massive profits, if any.

    Of course, just because libraries aren’t for profit doesn’t mean you don’t pay librarians and raise money to keep the library running.

    Same thing with activitypub.

    To the point of growth, yes activitypub needs to grow tons to rival any of the big networks but I would rather take our time building the fediverse brick by brick and do it right then try to immitate a VC funded network and end up with the same toxic culture they inveitably seed.

    1. Indeed. All people and organizations need to take part in the decentralized movement, as well. I think what would help to authenticate it with the rest of the world who sees it as an unknown would be big orgs and small participating. I see it with several open source organizations; Debian, the fediverse itself, and others, but until the bigs start getting involved, especially the tech companies, it’s probably never going to be as big, hence keeping the centralized services in power.

  7. I guess the money problem can be solved by GNU Taler (an electronic wallet). If, on the Federation, people hang out with the GNU Taler browser plug-in, then everybody has a wallet with him.her. You can have $, Euros, Bitcoins, new local currencies, etc…. There are then no significant fees for transactions, enabling the possibility for a one-click micropayment. This could also bring crowdfunding and markets straight on the platform.

    If you can buy food on the Federation easily, then you’ll never have to worry about money anymore. As a small scale farmer, I’ll be more than happy to share my profits (if I ever make any) with the Federations’ developpers.

    I guess the people who will start selling dope instead of food will think the same, except that they, for sure, will make profit.

    Do I miss anything here, or is this really a short-term possibility ?

    Money seems to be a problem, but I think it is the solution for large scale migration towards the Federation : When money will be there, everybody will be there.

    Also, I’d love less articles about Mastodon. It is popular, but it’s not what makes us dream about the future. I think it’s important to popularize the diversity of the Federation : Hubzilla, Funkwhale, Peertube, Matrix, Plume, WriteFreely, PixelFed etc…

Leave a Reply

Your email address will not be published. Required fields are marked *