Open Social

The protocol is the API.

Open Social

September 26, 2025

Pay what you like

Open source has clearly won. Yes, there are plenty of closed source products and businesses. But the shared infrastructure—the commons—runs on open source.

We might take this for granted, but it wasn’t a foregone conclusion thirty five years ago. There were powerful forces that wanted open source to lose. Some believed in the open source model but didn’t think it could ever compete with closed source. Many categories of tools only existed as closed source. A Microsoft CEO called open source cancer—a decade before Microsoft has rebuilt its empire around it. The open source movement may not have lived up to the ideals of the “free software”, but it won in industry adoption. Nobody gets fired for choosing open source these days. For much crucial software, open source is now the default.

I believe we are at a similar juncture with social apps as we have been with open source thirty five years ago. There’s a new movement on the block. I like to call it “open social”. There are competing visions for what “open social” should be like. I think the AT Protocol created by Bluesky is the most convincing take on it so far. It’s not perfect, and it’s a work in progress, but there’s nothing I know quite like it.

(Disclosure: I used to work at Bluesky on the Bluesky client app. I wasn’t involved in the protocol design. I am a fan, and this post is my attempt to explain why.)

In this post, I’ll explain the ideas of the AT Protocol, lovingly called atproto, and how it changes the relationship between the user, the developer, and the product.

I don’t expect atproto and its ecosystem (known as the Atmosphere) to win hearts overnight. Like open source, it might take a few decades to become ubiquitous. By explaining these ideas here, I’m hoping to slightly nudge this timeline. Despite the grip of today’s social media companies, I believe open social will eventually seem inevitable in retrospect—just like open source does now. Good things can happen; all it takes is years of sustained effort by a community of stubborn enthusiasts.

So what is it all about?

What open source did for code, open social does for data.

Before Social

The web is a beautiful invention.

You type https://alice.com and you end up on Alice’s website.

Or you type https://bob.com and you end up on Bob’s website.

In a sense, your browser is a portal to millions of different worlds, each with its own little jurisdiction. Only Alice decides what appears on Alice’s website. Only Bob decides what appears on Bob’s website. They meaningfully “own their data”.

This doesn’t mean that they’re isolated. On the contrary, Alice can embed Bob’s picture with an <img src>, and Bob can link to Alice’s page with <a href>:

Alice and Bob can link to each other, but they remain in charge of their sites.

What do I mean by saying Alice and Bob are in charge of their own sites? Even if they’re not physically hosting their content on their own computers, they could always change hosting. For example, if Alice’s hosting provider starts deleting her pages or injecting ads into them, Alice can take her content to another host, and point https://alice.com at another computer. The visitors won’t need to know.

This is important. Hosting providers have no real leverage over Alice and Bob. If the hosting provider “turns evil” and starts messing with your site, you can just walk away and host it elsewhere (as long as you have a backup). You’re not going to lose your traffic. All existing links will seamlessly resolve to the new destination.

If Alice changes her hosting, Bob won’t need to update any links to Alice’s website. Alice’s site will keep working as if nothing had happened. At worst, a DNS change might make it inaccessible for a few hours, but then the web will be repaired:

Imagine how different the incentives would be if links were tied to physical hosts!

If changing a hosting provider caused Alice to lose her traffic, she would think many times before changing providers. Perhaps she’d stick with her existing provider even if it was messing with her site, as losing her connections is even worse. Luckily, web’s decentralized design avoids this. Because it’s easy to walk away, hosting providers are forced to compete, and hosting is now a commodity.

I think the web is a beautiful idea. It links decentralized islands controlled by different people and companies into one interconnected surface that anyone can index and navigate. Links describe a relationship between logical documents rather than between physical servers. As a result, you’re not a hostage to your hosting.

As a wise person said, in theory, there is no difference between theory and practice, but in practice there is. So what’s been happening with the web?

Closed Social

In the early 90’s, the main way to publish something on the web was to have your own website. Today, most people publish content by using a social media app.

Alice and Bob are still publishing things. But instead of publishing at domains like alice.com and bob.com, they publish at usernames like @alice and @bob allocated by a social media company. The things they publish are not HTML pages, but app-specific entities such as profiles, posts, comments, likes, and so on.

These entities are usually stored in a database on the social company’s servers. The most common way to visualize a database is as a sequence of rows, but you could also visualize it as a graph. This makes it look very similar to web itself:

What does this social graph enable that a web of personal sites doesn’t?

The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious. App-specific entities such as posts and likes have a richer structure: you can always turn them into HTML documents later, but you can also aggregate them, filter them, query, sort, and recombine them in different ways before that. This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.

Where this really shines, though, is when many people use the same social app. Since everyone’s public content is now in a single database, it is easy to aggregate across content published by many people. This enables social features like global search, notifications, feeds, personalized algorithms, shared moderation, etc.

It’s specifically this social aggregation that blows the “personal sites” paradigm out of the water. People are social creatures, and we want to congregate in shared spaces. We don’t just want to visit each other’s sites—we want to hang out together, and social apps provide the shared infrastructure. Social aggregation features like notifications, feeds, and search are non-negotiable in modern social products.

Today, the most common way to implement these features is shaped like this:

There still exists a web-like logical model of our data—our profiles, our posts, our follows, our likes, all the things that we’ve created—but it lives within some social app’s database. What’s exposed to the web are only projections of that model—the Home screen, the Notifications screen, the HTML pages for individual posts.

This architecture makes sense. It is the easiest way to evolve the “personal sites” paradigm to support aggregation so it’s not surprising today’s apps have largely converged on it. People create accounts on social apps, which lets those apps build aggregated features, which entices more people to sign up for those apps.

[...]

Original source