When people say "Bluesky," they usually mean one of two different things, and conflating them causes problems. The first is bsky.app: a website, a social network, something that looks and functions a bit like Twitter used to before Twitter started looking and functioning the way it does now. The second is the AT Protocol: the underlying technical infrastructure on which bsky.app is built, and on which a growing number of other applications are also built. These are not the same thing, and treating them as synonymous misrepresents how the whole enterprise works.
Bluesky PBLLC – the company – controls bsky.app. It does not control the AT Protocol network. The distinction matters more than it might first appear.
Where This Came From
The AT Protocol did not emerge fully formed from nowhere, and the history is relevant to understanding why it is designed the way it is.
In December 2019, Jack Dorsey – then still CEO of Twitter – announced that the company was funding a small independent team with a specific brief: develop an open, decentralised standard for social media. The stated goal was for Twitter itself to eventually become a client of whatever that standard turned out to be. The internal project name was Bluesky.
By 2021, the project had spun out as an independent company, Bluesky Social PBC – a public benefit corporation – with Jay Graber, a software engineer with a background in decentralised technology, appointed as CEO. Twitter maintained a financial relationship with the new entity for a while. Then, in late 2022, shortly after Elon Musk completed his acquisition of Twitter, that service agreement was terminated. Neither party said much about the reasons. The timing was suggestive enough.
The AT Protocol specifications were published publicly in October 2022. The Bluesky app launched in an invite-only beta in February 2023, and became publicly available in February 2024. Dorsey himself quit the board in May 2024 – he has since been fairly critical of the direction the project has taken, which is its own story. As of early 2026, the network has over 42 million users (currently 44.5 million as of writing), and the IETF – the body that standardises the fundamental protocols of the internet – has chartered a working group to develop AT Protocol as a formal standard. That last part is not nothing. It suggests the protocol has reached a point where the broader technical community considers it worth taking seriously.
The key thing to understand about this history is that the AT Protocol was designed by people who had watched centralised social media fail, repeatedly, in specific and predictable ways. That experience is legible in every architectural choice.
How the Architecture Works
The easiest analogy for the AT Protocol is email. When you send an email from a Gmail account to someone using Outlook, you are not sending it through Google – you are using a shared protocol, SMTP, that both services understand. Neither Google nor Microsoft controls that protocol. Anyone can build a mail server that speaks it.
The AT Protocol works on a similar principle, except for social media data rather than email. The network has a few distinct layers, and it helps to understand what each of them does.
At the base is the Personal Data Server, or PDS. This is where your account data lives: your posts, your follows, your likes, everything you create or do. Bluesky runs the largest PDS, at the bsky.social cluster nicknamed the Mushroom cluster, which is where most people's data currently sits. But third parties can run their own, and so can individuals – I have my account on eurosky.social (ran by eurosky.tech.)
The PDS stores your data as a cryptographically signed repository, which means its contents can be verified as authentic without trusting the server operator.
Above that sits the Relay (sometimes called the Big Graph Service, or BGS), which continuously crawls all PDSes it knows about and builds an aggregate index of everything happening across the network. Think of it as the infrastructure layer between where data is stored and where it is consumed.
Applications then connect to that index via AppViews – the layer that takes raw protocol data and shapes it into something a specific application needs. Bluesky's AppView turns the underlying records into a social feed, and there are ones ran by other players like Blacksky Algorithms. A completely different application might read the same data and present it as something else entirely.
This separation of concerns is the point. Your data lives on a PDS. Applications read from it. No single application controls the data, and switching between applications does not require migrating or copying anything – you are accessing the same underlying layer through a different interface.
Handles, DIDs, and Why You Have Both
The identity system is the part of the AT Protocol that tends to confuse people most, but it is also the part that is most worth understanding, because it is where the "your account is actually yours" claim becomes concrete.
Every account on the AT Protocol has two distinct identifiers. They serve different purposes and it is important not to conflate them.
The handle is the human-readable one, also called an alias: something like @ewancroft.uk, or @alice.bsky.social. It is what you show people. It is mutable – you can change it. And crucially, if your handle is your own domain name, it serves as a form of verification: the protocol proves you control the handle by checking for either a DNS record or a file at a known path on that domain. This is why domain handles matter. @ewancroft.uk tells you that the account holder controls ewancroft.uk. @alice.bsky.social tells you only that alice has an account on Bluesky's service, which Bluesky controls and could theoretically revoke.
The DID (Decentralised Identifier) is the stable, permanent, cryptographic one: something like did:plc:ofrbh253gwicbkc5nktqepol. It never changes. Under the hood, all software in the AT Protocol ecosystem uses the DID to refer to accounts, not the handle – the handle is a human-friendly alias that resolves to the DID. This means you can change your handle, move between PDSes, even change your domain, and your social graph – the follows, the followers, the interaction history – comes with you intact, because everything is anchored to the DID rather than to any mutable display name or service.
The protocol supports two DID methods. did:plc is a system developed specifically for the AT Protocol and maintained by Bluesky. did:web is a W3C standard that ties the identifier to a domain you control – if you run your own PDS and use did:web, your identity is anchored to your own infrastructure and does not depend on Bluesky's registry at all. There are reasonable criticisms of did:plc specifically – it does introduce a point of centralisation, since Bluesky operates the directory as of writing – and those criticisms are worth being aware of. The protocol is not perfectly decentralised in every dimension. What it is, is significantly more portable and user-controlled than anything that existed before it.
The practical upshot: your @username.bsky.social handle is somewhat analogous to a username on a platform. Your own domain as a handle is closer to owning your own address. Your DID is the permanent record beneath both.
The Apps
This is not a comprehensive directory. It is a selection of things that demonstrate the range of what is already being built on the protocol, because the answer to "what else is on the AT Protocol" is increasingly: quite a lot. Streamplace is an open-source livestreaming platform built on the AT Protocol. A Twitch comparison is apt: it is a space for live video, with the social layer – follows, interactions, community – drawn directly from the protocol. The difference is that the infrastructure is open, the source code is available, and your audience is portable. If you already have a following on Bluesky, it carries over. No starting from scratch.
Leaflet is a publishing platform – blogs, newsletters, the full spectrum of long-form writing – built on the Atmosphere, which is what the AT Protocol ecosystem is sometimes called. The Substack comparison is the obvious one, though Leaflet's approach to data ownership makes it a more principled choice: your content is stored as protocol records, not locked inside a proprietary platform. You can use a custom domain. The base tier is free. This post is, in fact, published via Leaflet.
teal.fm is a music tracking and scrobbling service on the AT Protocol – a Last.fm for the decentralised web, tracking what you listen to and building a listening history that is yours. The underlying data model means that listening records are protocol records: portable, interoperable, not dependent on teal.fm remaining solvent for the history to persist. For anyone who has ever watched a platform quietly deprecate its music features and lost years of listening data in the process, the appeal is fairly self-evident. Do bare in mind that Teal is technically not launched as of right now, but you can use its lexicons (à la file types) already.
Popfeed is the Letterboxd-adjacent option: a place to log films, television, music, and games, with reviews and ratings, built on the ATProto social graph. Because it uses the same protocol, your Bluesky following carries over immediately. You are not reconstructing a community from scratch; you are reading the same one through a different lens.
If You Are Already on Bluesky and Want a Different Interface
This is also worth mentioning, because the protocol-as-infrastructure point applies to clients as well as to entirely separate applications.
Witchsky, built by Jollywhoppers, is a fork of Bluesky's official open-source client, aimed at power users, developers, and anyone who finds the default interface a little sparse. It adds features and quality-of-life improvements that the official app does not have – including embedded Streamplace support for livestreams. It connects to the same network, reads the same posts, talks to the same people. It is simply a different window onto the same underlying data.
This is the point, and it is the reason the distinction between bsky.app and the AT Protocol matters. Bluesky the company made a choice to build on an open protocol rather than a closed one. That choice has consequences. Other developers can build on the same protocol. Other clients can read the same data. Other services can participate in the same social graph. The network is not bsky.app's to own, and the data is not bsky.app's to hold.
Why This Matters
The pattern in every social platform of the past two decades has been the same: network grows, becomes indispensable, terms of service tighten, third-party clients get cut off, API access becomes prohibitively expensive, the platform enshittifies, and the community either adapts or evacuates. Every time. Consistently.
The AT Protocol is an attempt to make that cycle structurally harder, if not impossible. Your data lives on a PDS you can control or move. Your identity is anchored to a DID that no platform can revoke. Your social graph follows you between applications. A domain handle you own is verified against DNS infrastructure that Bluesky does not control. These are not marketing claims – they are the logical consequences of how the protocol is built.
Whether the experiment succeeds will depend on adoption, on the ecosystem that grows around it, and on whether the protocol remains genuinely open as the network scales. Those are real unknowns. But the infrastructure, at least, is designed with the right lesson in mind.
The apps above are evidence that people are building seriously on it. That seems worth knowing about, and worth distinguishing clearly from the question of what one company's website is doing.