Back

Why ActivityPub is the future

Eugen Rochko

CEO / Founder

We often tout things like “Mastodon is based on open web protocols” as one of its advantages. I want to elaborate why exactly that’s a good thing.

As a refresher, Mastodon implements the so-called ActivityPub protocol to enable Mastodon servers to talk to each other; that’s the basis of the “federation” we also like to bring up. Federation is what you already know from e-mail, even if you may not know it by name: It’s the concept of servers hosting users that can talk to users from other servers. That protocol pins down on paper how exactly such inter-server communication would look like, using a vocabulary that can be applied for a variety of purposes. And here’s the kicker:

The social network that is Mastodon isn’t really Mastodon. It’s bigger. It’s any piece of software that implements ActivityPub. That software can be wildly different in how it looks and what it does! But the social graph–what we call the people and their connections–is the same.

  • Mastodon is the software built around 500-character text posts.
  • You want a video platform? That’s PeerTube.
  • You want something centered on photos and pictures? PixelFed is here.
  • You want to write long, rich blog posts? Plume is in development.

That’s not to mention a multitude of variations on the same concepts. PeerTube and PixelFed won’t be the only ones in their categories. For example, Misskey and Pleroma have a similar use case as Mastodon, but they make different choices in programming languages, design and functionality.

All of these platforms are different and they focus on different needs. And yet, the foundation is all the same: people subscribing to receive posts from other people. And so, they are all compatible. From within Mastodon, Pleroma, Misskey, PixelFed and PeerTube users can be followed and interacted with all the same.

And that’s the strength of using open web protocols. When you decide to switch to Mastodon, you’re not just gambling on the success of one project. You can be certain that regardless what happens with Mastodon, the network will live on and flourish. Newer and better software will be born within this ecosystem, but you will never have to drag all your friends and followers someplace else again–they’ll already be where they need to be.

If Twitter shuts down, you’ll lose your followers. If Facebook shuts down, you’ll lose your friends. For some platforms, it’s not a question of “if”, but “when”. Such events are usually followed by a scrambling into a variety of different platforms, where you inevitably lose some people as you have to make a choice which one to stay on. This happened before. But it doesn’t have to happen again. Use the federated web. Join Mastodon.

Guides

How to implement a basic ActivityPub server

Today we’ll be looking at how to connect the protocols powering Mastodon in the simplest way possible to enter the federated network. We will use static files, standard command-line tools, and some simple Ruby scripting, although the functionality should be easily adaptable to other programming languages. First, what’s the end goal of this exercise? We want to send a Mastodon user a message from our own, non-Mastodon server. So what are the ingredients required? The message itself will be formatted with ActivityPub, and it must be attributed to an ActivityPub actor. The actor must be discoverable via Webfinger, and the delivery itself must be cryptographically signed by the actor.

Eugen Rochko

CEO / Founder

New Features

Mastodon and the W3C

Mastodon is a free, open-source federated social network spanning over 800,000 users spread across more than 2,000 servers. Mastodon v1.6 is here, and it is the first Mastodon release which fully implements the ActivityPub protocol. ActivityPub is a new federated messaging protocol developed by the World Wide Web Consortium (W3C) which aims to fix the shortcomings of past standards like OStatus. Mastodon is one of the first platforms, and certainly the first major platform to implement this new standard and prove it in the wild. It was a natural upgrade for our project, as we long ago reached the limits of what OStatus was capable of. And what we needed was better privacy, better defaults, better cryptographic verifiability, and better distribution mechanisms.

Eugen Rochko

CEO / Founder