Given all the talk lately of Threads, Mastodon, and ways that people can publish on their own sites, I thought it might be worth revisiting what the fediverse actually is — and why an organization might want to integrate with it.

My focus is on media organizations, but remember that just about every company is, in some sense, a media organization: newsrooms, for sure, but also marketing organizations, engineering teams hoping to hire great talent, non-profits that need to spread their message and make an impact, creatives who want to promote their work, and so on.

Here’s the summary: the fediverse allows media organizations to directly own their relationships with their audiences in a way that they’ve previously only been able to approximate with email newsletters. It gives them full, deep analytics about what their audiences care about in a way that can’t be achieved with newsletters or news aggregators, allows publishers to reach them directly, and will grow to a potential audience of at least 172 million people by the end of the year.

How did I come to those conclusions? I’ll break it down.

Really simple syndication

It all started with syndication feeds. The word “syndication” here is actually misleading: they’re a way to subscribe to the content put out by a publisher, such that if you subscribe to a publisher’s feed in your feed reader, you will receive every article they publish in your reader.

You already know about RSS (Really Simple Syndication), which is one open format for feeds, used by readers like Feedly and Reeder. RSS is also what powers podcasts behind the scenes.

RSS isn’t the only kind of syndication feed, however. For example, if you’re on a Mac or an iPhone, you might use Apple News, which is a feed reader that’s been optimized for a curated set of news publishers. Its underlying technology is not a million miles away from an RSS reader.

Each reader application performs the following steps:

1. Load the feeds for all the publishers a user has subscribed to, directly from the publishers’ websites
2. Check for any new articles in each of the feeds that the user hasn’t seen before
3. Place these articles in an inbox for the user to read

A feed reader is a one-directional broadcast relationship. Once you subscribe to a feed, you will receive newly-published articles from that publisher. What you can’t do is reply to those articles, and there’s also no standard way to re-share them. Syndication feeds are for reading only: you receive articles from the publisher but have no way of sending anything back to them.

It’s worth adding that I’m using “articles” here as a shorthand: feeds can contain any kind of content. A podcast is just a syndication feed that happens to contain audio; a podcast player is a feed reader optimized to play audio. It’s also perfectly possible for a feed to contain video or even interactive applications. It just so happens that most feeds are text and audio, but they don’t have to be that way.

While curated apps like Apple News do let publishers know how many people are reading their content (which is often multiples of the number of people who read the publisher’s website directly), this is almost impossible to achieve with RSS. In most cases, if a publisher is producing a feed, they have no idea how many people are subscribed to it — let alone who they are, what else they’re interested in, and who else they’re subscribed to.

Email newsletters

Publishers don’t know who is subscribing to their RSS feeds, or how effective those feeds are. Meanwhile, while they try and reach their audiences via social media, companies like Meta have long since been intermediating between publishers and their followers, often charging publishers to be seen by more of the people who already opted in to following them.

Increasingly, the response has been to establish email newsletters:

• Publishers can be reasonably sure that emails will be received by readers
• They can change email providers without losing email subscriptions
• Email open rates can usually be measured
• Email subscribers are more likely to donate or become paid subscribers

It’s considered to be a direct relationship because email providers don’t intermediate. The publisher receives the subscriber’s email details, and the reader knows they’ll receive all of a publisher’s emails.

However, publishers really only know three things about email subscribers:

1. Their email address
2. Whether they open their mail
3. Whether they click on anything in their mail

In particular, they don’t know who those people are, what they’re interested in, and who else they’re subscribed to. Often they’ll run an annual survey to get a stronger sense of that information — primarily so they can figure out how to serve that audience with content tailored for them, but also so they can figure out if they’re reaching a diverse enough audience, and so on. However, publishers are not likely to get any other information about them, save for an occasional email reply from around 2% of the most-engaged subscribers.

What’s different on the fediverse

The fediverse is a decentralized social layer for the whole web. One way to think of it is if the entire web was a social network, with profiles, content, and actions on that content.

It’s the best of the worlds I’ve discussed in the following ways:

• Publishers know who is subscribing to their content
• Everyone has a profile, where their other subscriptions can be traversed, so publishers can understand what their readers are interested in
• It’s incredibly easy for a reader to respond to, or interact with, content, making their opinions and preferences known
• All of the above happens in a direct, non-intermediated way: content is published on the publisher’s website, and it is subscribed to directly and received by the reader on publication (at least, most of the time; more on this in a moment)

Like pure syndication, the fediverse is essentially based on feeds. Here, rather than just publishers having a feed, everyone gets one.

Not everyone wants to publish articles of their own, but you possibly might want to “like” or re-share something that someone else published. When feeds contain actions as well as content, we call them activity streams. “Ben Werdmuller liked Evan Prodromou’s article” is an example of an activity.

In the above example, it’s not particularly useful for me to like Evan’s article if he doesn’t get to know about it. So in the fediverse, each reader can receive other peoples’ actions to its inbox, even if the user hasn’t subscribed to them. Evan might not subscribe to me, but if I click to “like” one of his articles, my reader will send that activity to his inbox, and he’ll be notified.

There is, of course, much more to it technically behind the scenes. But at its core, the fediverse really is just feeds of content and activities, with a little bit of magic to let people know when people are talking about them. (You might have heard of ActivityPub: this is the protocol used to enable this magic, as well as to help readers find a publisher’s feed to begin with.)

Remember that syndication feeds have a uni-directional relationship: the publisher creates content and the user subscribes and reads. In contrast, fediverse feeds have a bi-directional relationship: the publisher creates content and the user can subscribe, read, like, re-share, quote, and more.

Every fediverse application is just a feed reader that lets you respond to content, perform activities like “liking” and “re-sharing” it, and publish your own.

This means that, yes, Mastodon is, at its core, a feed reader. Threads will also be a feed reader once it fully supports ActivityPub. It just so happens that most of these feeds tend to contain short Twitter-style content right now, but they don’t have to. They can contain articles, audio, video, interactive content — all the same content possibilities as syndication feeds, as well as a range of activities on that content.

Importantly for media companies, whereas a publisher doesn’t really know who might be subscribing to their syndication feeds, a publisher knows exactly who is subscribing to their fediverse feeds. Subscriptions are just another activity that they’re notified about — which allows them to measure growth over time, and even reach out to their individual subscribers directly if they want. Each subscriber has a profile that lists who else they’re following, allowing their interests to be measured in aggregate.

Okay, but who’s going to use it?

The fediverse does not provide identity portability. That is to say, if you have an account on Threads and you want to move to Mastodon, there’s no standard way to move from one to the other. While any application on the fediverse allows users to interact with content produced by any other application on the fediverse, there’s nothing to prevent users from being locked in to any one of these applications. If I build a following on Threads, I can’t move that following to Mastodon.

While that might seem like a bug, it’s a characteristic that can help platforms like Threads feel comfortable supporting the fediverse. It allows their users to read and interact with an expanding world of content, but it’s not an offramp for those users to more easily leave the platform. Finally, although content can be consumed using any fediverse reader, a lot of it will look better on the platform it originated from, so platforms may gain users who discover them through reshared fediverse content.

So the benefits for platforms are:

• Platforms have a world of content and users they can plug into from day one, so they solve the cold start problem where a platform seems empty before lots of people have joined
• Users are incentivized to stay on a platform once they’ve joined it
• Users can discover new platforms through content that’s been shared on the fediverse

The result should be that more platforms support the fediverse over time. Currently the biggest platforms are Mastodon, at 12 million users across many installations across the web. Over the next year it will be joined by Threads, who has over 160 million users. Unlike many of the decentralized social web efforts in the past, the fediverse will have hundreds of millions of users as a baseline.

Publishers who are there and ready when Threads fully plugs in its fediverse connectivity will be at a distinct advantage.

About those direct connections

I mentioned that the fediverse wasn’t intermediated: a publisher can be reasonably sure that a reader will receive its content.

While a publisher’s website can be plugged into the fediverse so that a reader can subscribe directly, whether that reader actually gets to see the content does depend on the platform they’re is using. In particular, it’s reasonable to assume that Threads, which is owned by Meta, is more likely to create intermediation between the publisher and the reader. Meta has form for this: Facebook Page owners famously need to pay to promote posts if they want to be sure their communities can see them. It’s not clear how Threads will monetize, but it’s possible that this sort of content promotion will be part of its strategy.

The good news is that the underlying protocols are open and anybody can build something new on top of them. While Mastodon and Threads are both optimized for short-form content, other platforms already exist: Pixelfed is optimized for photographs, for example, and Lemmy for Reddit-style conversations. It’s highly likely that we’ll see fediverse software that works more closely to Apple News or a traditional feed reader, optimized for longer-form web content. Meta isn’t the only game in town and can’t dictate how the wider fediverse network functions.

How hard is it for a publisher to plug in?

The effort required to connect a website to the fediverse is very low. Publishers that use WordPress as their underlying CMS can add an existing ActivityPub plugin that is also available to hosted WordPress clients. Ghost has indicated that it’s exploring integrating with ActivityPub. Bridgy Fed also helps connects websites to the fediverse. (Known, which my website is built on, has contracted to build ActivityPub support in the first few months of this year.)

This support will only increase over the next year, particularly as Threads gets closer to releasing its full fediverse compatibility. It’ll only become easier and easier to plug in.

So should I, as a publisher, experiment with it?

Yes.

Don’t throw all your eggs into this basket, but the barrier to experimentation is so low, and the potential upside is so high, that it’s absolutely worth your time to experiment.

So should I, as a software developer, experiment with it?

Also yes. As you’ve read, there are lots of opportunities for use cases on the fediverse that haven’t quite been seen to fruition yet. There is a lot of potential here for both new and existing teams to create tools that provide a lot of value to an already-established and growing audience.

More libraries and APIs are becoming available every day to help you build fediverse compatibility. The barrier to entry is only getting lower — so the time to get established is now.