Werd I/O

Tantek Çelik has posted a lovely encapsulation of the indieweb:

The #IndieWeb is for everyone, everyone who wants to be part of the world-wide-web of interconnected people. The social internet of people, a network of networks of people, connected peer-to-peer in human-scale groups, communities of locality and affinity.

This complements the more technical description on the indieweb homepage:

The IndieWeb is a community of independent and personal websites connected by open standards, based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.

I first came across the indieweb movement when I’d just moved to California. Tantek, Kevin Marks, Aaron Parecki, Amber Case, and a band of independent developers and designers were actively working to helping people own their own websites again, at a time when a lot of people were questioning why you wouldn’t just post on Twitter and Facebook. They gathered at IndieWebCamps in Portland, and at Homebrew Website Camp in San Francisco.

One could look at the movement as kind of a throwback to the very early web, which was a tapestry of wildly different sites and ideas, at a time when everybody’s online communications were templated through web services owned by a handful of billion dollar corporations. I’d prefer to think of it as a manifesto for diversity of communications, the freedom to share your knowledge and lived experiences on your own terms, and maintaining the independence of freedom of expression from business interests.

A decade and change later and the web landscape looks very different. It’s now clear to just about everyone that it’s harmful for all of our information to be filtered through a handful of services. From the Cambridge Analytica scandal through Facebook’s culpability in the genocide against the Rohingya people in Myanmar, it’s clear that allowing private businesses to own and control most of the ways we learn about the world around us is dangerous. And the examples keep piling up, story after story after story.

While these events have highlighted the dangers, the indieweb community has been highlighting the possibilities. The movement itself has grown from strength to strength: IndieWebCamps and Homebrew Website Clubs are now held all over the world. I’ve never made it to one of the European events – to my shame, it’s been years since I’ve even been able to make it to a US event – but the community is thriving and the outcomes have been productive.

Even before the advent of the fediverse, the indieweb community had built tools to allow websites to connect to each other as a kind of independent, decentralized social web. Webmention, in conjunction with lightweight microformats that extended HTML to provide semantic hints about the purpose of content on a website, allowed anyone to reply to any website article using a post on their own site – not just that, but they could RSVP to events, send a “like”, reshare it, or use verbs that don’t have analogies in the traditional social networks. The community also created micropub, a simple API that makes it easy to build tools to help people publish to their websites, and a handful of other technologies that are becoming more and more commonplace.

In the wake of the decline of Twitter, Google’s turn towards an AI-driven erosion of the web, and a splintering of social media, many publishers have realized that they need to build stronger, more direct relationships with their communities, and that they can’t trust social media companies to be the center of gravity of their brands and networks. For them, owning their own website has regained its importance, together with building unique experiences that help differentiate them, and allow them to publish stories on their own terms. These are truly indieweb principles, and serve as validation (if validation were needed) of the indieweb movement’s foundational assumptions.

But ultimately it’s not about business, or technology, or any one technique or facet of website-building. As Tantek says, it’s about building a social internet of people: a human network of gloriously diverse lived experiences, creative modes of expression, community affinities, and personalities. The internet has always been made of people, but it has not always been people-first. The indieweb reminds us that humanity is the most important thing, and that nobody should own our ability to connect, form relationships, express ourselves, be creative, learn from each other, and embrace our differences and similarities.

I’m deeply glad it exists.

Also posted on IndieNews

CNN reports that the NSA has been buying internet data as a way to track Americans without a warrant:

[Oregon Democratic Senator Ron] Wyden, one of Congress’ most vocal privacy advocates, said he spent nearly three years pushing to be able to disclose the NSA practice and only succeeded when he placed a hold on the nomination of Nakasone’s successor for NSA director, Lt. Gen. Timothy Haugh. In a similar disclosure in 2021, Wyden revealed that the Defense Intelligence Agency had purchased commercially available smartphone location data without a warrant.

A few different tools are available to highlight software that tracks you across the websites you visit. The Markup’s Blacklight tests any individual website; the EFF’s Privacy Badger claims to protect your browser as you visit websites; Firefox has built-in privacy as standard. For the average user, however, the advantages might not be so obvious: so what if some firm I’ve never heard of sets a cookie in my browser? What does it matter that Google can see me? After all, they already have my search history.

While we can make tracking software visible, it’s harder to understand who the customers of this tracking data actually are. And that matters a lot, because that’s how your data is actually getting used. The companies that run the trackers are middlemen trying to make a profit; they’re interested in tracking you as well as possible. The real question is why you’re being tracked. Who has a use case for your information?

Some of those use cases are relatively benign: box stores trying to understand what they should advertise to you, for example. But those customers also include law enforcement and the security services, who have found that they can discover information that would ordinarily necessitate obtaining a warrant simply by paying a data broker for it.

H.R. 4639, the Fourth Amendment Is Not For Sale Act, which would ban this practice, was introduced in Congress last year. That’s a start, but it wasn’t voted on, let alone passed. There’s a long legislative road ahead before we see rules barring warrantless surveillance through data brokers.

Even if you feel like you’ve got nothing to hide, consider that this puts you in a privileged group. I like Edward Snowden’s comment on the right to privacy:

Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. A free press benefits more than just those who read the paper.

For example, consider a pregnant person who is trying to find information about finding an abortion. Those searches — or carrying a cellphone with location services enabled that contains apps which report location in the background while visiting a reproductive health clinic — create a trail of internet traffic that could potentially be obtained by law enforcement in a state that disallows abortions. That information exists, despite claims by Google and others that it would be deleted to avoid this situation:

A year and a half has passed since Google first pledged to delete all location data on users’ visits to abortion clinics with minimal progress. The move would have made it harder for law enforcement to use that information to investigate or prosecute people seeking abortions in states where the procedure has been banned or otherwise limited. Now, a new study shows Google still retains location history data in 50% of cases.

A few years ago, it emerged that a branch of the military was buying data from Muslim prayer apps. Back then, developers admitted that they had no idea who was buying the data:

Some app developers Motherboard spoke to were not aware who their users' location data ends up with, and even if a user examines an app's privacy policy, they may not ultimately realize how many different industries, companies, or government agencies are buying some of their most sensitive data.

While blocking trackers is absolutely a way to protect user privacy, I believe these events point to a need for privacy policies to identify the people and organizations who actively purchase data (both directly and at the data broker level). That means data brokers need to be far more transparent with the websites and software developers they partner with, so that they, in turn, can be more transparent with their users.

It’s clearly not something that would happen without legislation: given the optics and public sentiment around surveillance, who would want to be seen to be purchasing peoples’ private information? But adding sunlight to a mix of privacy protections that also include purchasing restrictions on government and technical restrictions on trackers can only be helpful.

While we certainly should care about how our activity is tracked, we all really care about who has access to our private information. We should have the right to find out.

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.