The Data Layer Was the Missing Piece
The web solved a similar problem with hosting. When publishing was tied to a personal site, a hosting provider that misbehaved could be swapped out without breaking links or losing traffic. Because walking away was cheap, providers had to compete on merit, and hosting became a commodity. The key was that links pointed to logical documents, not physical servers.
Social apps regressed on that principle. Content such as profiles, posts, comments, and likes lives in somebody’s database, under usernames like @alice assigned by the platform. What the public web sees are only projections: the home screen, the notifications screen, the HTML page for a single post. That architecture made sense for enabling social aggregation—search, feeds, moderation, notifications—across content from many people. But it also re-introduced the exact hostage dynamic the web had eliminated. If Alice’s platform turns hostile or dies, she can “export” JSON, but that data is ripped out of its social graph. It’s a dead archive, not a living presence. To keep her connections, she has to sever them—starting over from zero someplace else.
If you can’t leave without losing something important, the platform has no reason to respect you. And when the platform eventually falls to monetization pressure, an acquihire, or neglect, the only practical choice is resignation or exile.
That’s the problem that open social—and specifically the AT Protocol as conceived by Bluesky—aims to solve. What open source did for code, open social aims to do for data.
Portability Over Export
A quick disclosure: I used to work at Bluesky on the client app, not on the protocol, and this is my own take on why its design is compelling.
The standard response to the trap of platform lock-in is “data export.” But export treats the symptom without curing it. Export gives you a copy; it doesn’t give you the infrastructure to continue being social. A multi-megabyte JSON bundle of your activity is a fine memento but not a way to keep your audience.
The AT Protocol (atproto) is an attempt to make the social graph itself portable, so you can change providers the way you can change DNS servers or hosting providers for a website. The logical layer of your social presence—who you follow, what you post, what you like—is decoupled from the physical layer of any one company’s server.
That decoupling is what creates leverage for the user. If your provider starts injecting ads into every third post, or gets acquired by a conglomerate, or simply runs out of funding, you can move. Not by starting over, and not by shipping an archive around—but by pointing your existing identity and graph at a new host. All of your links and followers stay connected.
One Protocol, Many Aggregators
Separating the data layer from the aggregation layer is the core trick. In today’s app-centric world, the entity that indexes your content is the same entity that stores it, displays it, searches it, and moderates it. That’entity gets to be the sole gatekeeper of your social connections. Atproto doesn’t abolish aggregation—it just neutralizes its monopoly power in the social graph. Your data stays practical and queryable, not locked inside a single product from a single company.
I don’t expect atproto to reach ubiquity overnight. Like open source, it may take decades, and competing visions exist for what open social should be. I think AT Protocol is the most convincing take so far. It’s not perfect and it’s still in progress—but those megabytes of JSON you got on your way out of your last platform are dead data, and that is fundamentally a fixable problem.
Your Handle, Your Property
The most visible change in an open social world is the identity. Alice doesn’t have a username handed out by a platform; she goes by @alice.com because she owns the domain. That domain is her universal internet handle, usable across any open social app. For cases where she wants a separate, disconnected identity, she can own another handle and keep it private.
This isn’t a technical requirement that locks out non-technical users. Bob owns a domain too, even though he barely knows what one is. To him, @bob.com is just his internet handle. Open social apps can offer a free subdomain at signup, much like a free email address, or provide a guided flow to buy a domain. Users aren’t stuck with their first choice and can switch to a different domain later.
Owning your handle is the user-facing part of a much larger architectural shift. In today’s apps, your social graph—posts, likes, follows—sits in a proprietary database, isolated from the web. In the open social model, that data lives on the web itself. Alice’s posts and interactions are stored in a personal repository: a standard web server that implements the AT Protocol spec and serves her data as signed JSON. She can inspect it with open-source tools like pdsls, Taproot, or atproto-browser.
Bob gets a repository automatically when he signs up for his first open social app, without ever knowing it exists. It stores his data from all open social apps he uses.
Hyperlinked JSON, Not Database Rows
The data model is fundamentally different from a traditional social database. Instead of rows in a table, you have a web of hyperlinked JSON records. Every JSON record has an at:// URI, just as every HTML page has an https:// URI, allowing any record to link to another. The at:// protocol is a set of conventions layered on top of DNS, HTTP, and JSON.
The links between records express social connections. If Alice follows Bob, she has a follow record pointing to Bob’s profile record. If Bob comments on Alice’s post, his comment record links to her post record. Alice’s like record links to Bob’s comment. Everything Alice creates stays in her repository; everything Bob creates stays in his. This is all invisible to non-technical users, who don’t need to worry about where their data lives until something goes wrong.
Hosting is flexible. Alice’s and Bob’s repositories might run on the same machine, or be operated by different companies or communities. Alice could self-host; Bob might use a free service bundled with his first app. They could even run entirely different server implementations. As long as both follow the AT protocol, they can participate in the same web of JSON.
A key design point: https://alice.com and at://alice.com don’t need to resolve to the same server. This decoupling means owning a nice handle like @alice.com doesn’t force Alice to host her own data, tinker with her website, or even have a website at all. If she owns the domain, she can point at://alice.com at any server she chooses.
Should Alice become unhappy with her hosting, she can move her repository. The process requires some technical skill today, though tools are making it more accessible. Crucially, moving doesn’t require the old host’s cooperation, doesn’t disrupt her app logins, and doesn’t break any links. The web of links repairs itself automatically.
The consequence is meaningful ownership. Every piece of public data—posts, likes, comments, recipes, scrobbles—is hosted directly on the open web, not in a database subject to a CEO’s whims. Users can “walk away” from any service without losing their data or breaking links.
Apps as Content Management Systems
In this model, an open social app acts like a content management system for a subset of data living in users’ repositories. Your personal repository is analogous to a Google account, a Dropbox folder, or a Git repository, with data from different apps grouped into different “subfolders.”
When you post on Bluesky, the app writes that post into your repository. When you star a project on Tangled, Tangled writes that star into your repository. When you create a publication on Leaflet, Leaflet writes it into your repository as well. The pattern holds across all apps.
Your repository accumulates data from various open social apps over time. Because this data is open by default, you can inspect anyone’s public records by hitting their personal repository directly, without going through an app-specific API. The repository groups data by format to avoid naming collisions: Bluesky posts are stored alongside other Bluesky posts, Leaflet publications with other Leaflet publications, and so on. Each data format is controlled and evolved by the developers of the app that created it.
Since data from different apps lives together, apps can easily piggyback on each other. When signing up for Tangled, you can use your existing handle from Bluesky. Tangled can even prefill your avatar by reading the Bluesky profile record from your repository—no Bluesky API call required. This isn’t limited to avatars like Gravatar; it works for every piece of data. Any open social app can parse and use data created by any other app, with no API integrations to build and nothing to get locked out of. The protocol itself is the API.
This has significant implications for product lifecycles. If a service shuts down, its users’ data doesn’t vanish—it remains in their repositories. Someone can build a replacement, integrate some of the data, or create a forked projection of existing data. New apps also benefit from a reduced “cold start” problem. A new short-video app could bootstrap by reusing Bluesky’s follow records so users don’t have to rebuild their social graph. If that doesn’t suit the app, it can use its own follow records or offer a one-time import. Existing data is available for reuse and remixing.
Some apps are built explicitly around this remixing. Anisota is primarily a Bluesky client but natively shows Leaflet documents. Popfeed can cross-post reviews to both Bluesky and Leaflet. If Leaflet gains popularity, nothing stops Bluesky itself from supporting Leaflet documents as post attachments—a third-party client could even implement that feature first.
Open social frees up data the way open source freed up code. It ensures old data gets new life, people can’t be locked out of what they’ve created, and products can be forked and remixed. You don’t need a single “everything app” when data circulates freely across the web.
How Aggregation Works
A natural question arises for engineers: with millions of repositories, how do you query and aggregate data efficiently? You can’t search each user’s repository on demand.
The “singleplayer” case—a blogging app writing posts to a user’s repo and reading them back for display—needs no aggregation. But for network-wide features, apps avoid hitting user repositories constantly. Instead, they connect to a user’s repository via websocket. Every time a relevant record is created, updated, or deleted, the app updates its own database. This database isn’t the source of truth; it’s an app-specific cache for performance.
This same mechanism enables aggregation. An app listens to events from all its users’ repositories, writes them to a local database, and queries that database with no additional latency. It’s reminiscent of how Google Reader crawled RSS.
To avoid maintaining a million socket connections, apps listen to a stream that retransmits events from all known repositories on the network—a relay. The app can filter this stream to only relevant events. Leaflet, for instance, tracks pub.leaflet.* records but could also listen to app.bsky.feed.post records to show quotes from Bluesky discussions—which it already does.
The complete event stream from every known repository is publicly viewable and is dominated by Bluesky records since Bluesky is the most-used app. The primary relay is run by Bluesky, but independent implementations exist, such as the Blacksky community’s relay at wss://atproto.africa. It doesn’t matter which relay an app uses—everyone sees the same web.
Security is inherent to the design. Commits are cryptographically signed, so you don’t need to trust relays or caches. You can verify records haven’t been tampered with. This is why “AT” in AT Protocol stands for “authenticated transfer,” pronounced like “at,” not “ay-tee.”
As the ecosystem matures, more infrastructure is emerging: Graze helps build algorithmic feeds; Quickslice and Tap simplify indexing; Constellation and Slingshot enable backlink queries and cached record access. These are technical details, though. What matters is the bigger picture: a web where users own their identities and their data, and where apps can flourish, fail, and be forked without locking anyone out.
The shift ahead
The early, "personalized" web nailed data ownership, hosting independence, and linking. But it fell short on the social features we now take for granted—notifications, search, and feeds—which the closed social web innovated and scaled.
The cost of that innovation was exclusion. In the closed model, the web we collectively create no longer belongs to us; we're just rows in someone else's database. Open social flips this: our profiles, likes, follows, recipes, and scrobbles meaningfully belong to us. The data stops living inside products; instead, products aggregate over our data.
This shift blurs app boundaries. Any open social app can use, remix, link to, and build on data from any other open social app. The web we've created survives the demise of the products that helped create it, and developers can build new products to recontextualize it. No one can take it away.
As more products adopt this paradigm, a noticeable shift will occur. Users may never adopt technical vocabulary like "decentralization," but they understand when data from one app flows seamlessly into another. They may not care about "federation," but they notice when they log into a competing product and their data is already there, their reach intact. And they certainly understand when they're being mistreated.
For a long time, open social will depend on a community of stubborn enthusiasts who see the promise and tolerate the growing pains of a new ecosystem. That doesn't doom the effort—it's the history of every major community-driven change. Someone has to work through the kinks. Like open source, open social is a compounding effort: every mildly successful open social app lifts the rest, and shared infrastructure benefits everyone. At some point, open is bound to win.
The only question is how long it takes.
