The ATmosphere is not Bluesky. Except when it is?

I keep trying to write about something that's not the ATmosphere/atproto, but I keep gravitating to it, and so I'm just letting it happen.

This one is because I keep convincing myself the ATmosphere is distinct and separate from Bluesky, and then I remember something, or stumble upon something and once again become unsure.

So, this post is partly for myself to look back on whenever I become unsure again and partly because maybe somebody else will have this uncertainty, and maybe this will shed a bit of light for them.

I think there are two true facts and they seem contradictory:

1. The ATmosphere is decentralised.
2. Bluesky, the company, runs some important bits right now.

And the question I'm going to try to answer is: "if Bluesky, the company, went away tomorrow; what would break for me specifically?"

For me, that means my website; it builds most of its content from atproto records on a PDS, and I happen to use Bluesky's post lexicon for my notes (because my notes are just microblogging that I might've posted directly to Bluesky in the past).

I find it easier to think about this in layers, so that’s what I’m doing. But first…

What is Bluesky and what do all the words I'm about to read mean?

I think at the very least, "Bluesky" means two things:

• Bluesky, the app - the microblogging thing at bsky.app.
• Bluesky PBC, the company - the public benefit corporation that built said app, wrote the protocol and runs a lot of infrastructure.

Because this is probably going to be another acronym-heavy thing, here are some more definitions:

Now, the layers:

Identity: your handle

Your handle is a domain name. Mine is bekapod.dev, verified via DNS. Bluesky PBC has nothing to do with this; it's regular DNS, with all the pros and cons that implies:

• It's a stable bit of infrastructure that's likely not going anywhere anytime soon (caveat: I am not an expert on DNS and do not have any special interest in it lol).
• It's portable, and obviously if Bluesky goes away, I don't suddenly lose access to my unrelated domain name.
• You don't really "own" a domain name; you're effectively renting it (annual fees).
• If you forget to renew it, somebody else could take it.
• More serious things could happen that could mean you lose access to your domain name, but I don't think that's relevant for most individuals.

If, however, your handle is a *.bsky.social subdomain, that is Bluesky PBC's domain, and it exists at their discretion. This is also the easiest dependency to drop if you know how to update the DNS records on your domain.

Bluesky-dependent? Not really, so long as you use your own domain.

Identity: your DID

Underneath the handle is your DID, your permanent identifier that everything else branches from. This is where it's trickier in my opinion, because the dominant DID method, did:plc, was invented by Bluesky PBC, and the global PLC directory that stores everyone's identity operations is run by Bluesky PBC.

However:

• Bluesky PBC has said they are moving the directory to an independent organisation, a Swiss Association that has been chosen for jurisdictional neutrality. It will own the policies, the IP (including the plc.directory domain) and the future evolution of PLC. At time of writing, this is still in progress, though.
  • Creating an Independent Public Ledger of Credentials (PLC) Directory Organization
  • Mentioned in 2026 spring roadmap
• You can already run read replicas of the PLC directory (caveat being, it's a read replica, so resolution will work but any changes still need to go through the central directory) so the directory's contents are not something that only Bluesky PBC owns a complete copy of.

Separately, the keys that control your identity can be entirely yours (I wrote a whole other post about this). After my key migration, Bluesky hold no rotation keys for my DID and couldn't sign an identity operation for me even if they wanted to for some reason.

There's also did:web, which would remove the directory dependency completely, but there's a trade-off there. With did:plc, your domain is just a pointer, so if I lost access to bekapod.dev somehow (forgot to renew, wanted a change), I could point a new handle at the same DID and carry on with everything intact. With did:web, the domain is the identity, so if you lose the domain, I don't think there's a recovery path.

Bluesky-dependent? Right now, mostly yes, but it’s moving towards no. Independent governance is happening and read replicas are a thing.

Your data: the PDS

Maybe you’ve seen my other post about setting up my PDS, but if not: TLDR, my PDS is Cirrus running on Cloudflare Workers at at.bekapod.dev. Bluesky PBC doesn’t host it and can’t turn it off.

A lot of people’s data lives on Bluesky PBC’s PDS hosts because that’s the default when you sign up through the Bluesky app. Migration to a new host is supported and pretty well-known. Migrating doesn’t necessarily mean you have to run it yourself. Eurosky is building European hosting and infrastructure, so there’s a middle option between the default and the DIY route.

So if Bluesky PBC went away, my repo, content source, and records would all be fine.

Bluesky-dependent? I don’t think so. It’s easy enough to leave Bluesky, and I believe it’ll get even easier.

Distribution: relays & the firehose

My PDS emits events; in order for that to matter, something has to aggregate those events (+ the events from everyone else's PDS) into a "firehose" that other things can consume (drink??) from. The something is a relay, and Bluesky PBC does run a relay, and a lot of things use it.

For a personal site, this bit matters because:

• Outbound: the relay is how stuff I publish shows up in other apps (Leaflet, pckt, Bluesky, etc).
• Inbound: the recommendation counts on my site come from Constellation (a backlink index that sits downstream of a relay).

But now it’s a lot more doable for other people or groups to run relays:

1. They are less expensive to run now. Sync v1.1 reduced the bandwidth and storage a full-network relay requires, so that any motivated person could run one, not just a funded organisation.
2. Alternatives exist. Blacksky runs a full-network relay on its own implementation (rsky-relay) & it's serving traffic.

So if Bluesky went away, my posts would still be picked up by other relays, but there'd be a bit of downtime for any apps depending on Bluesky's relay.

Bluesky-dependent? I think in reality, yes, but in principle, no.

atproto Apps

An appview indexes records off the firehose and turns them into aggregations that help an app serve its purpose (e.g. feeds, counts, search). Apps in the ecosystem run their own over their own lexicons. For example:

• pckt, Leaflet and Offprint index site.standard publishing records
• BookHive indexes buzz.bookhive reading records
• Sifa indexes id.sifa professional profiles

Each of these only has to index its own collections, not the whole social graph, which makes them much smaller & cheaper, so when something I publish turns up on a standard.site reader, no Bluesky index is involved (though a relay is, see above).

The Bluesky app is mostly powered by an appview over app.bsky records, run by Bluesky PBC; architecturally similar to BookHive's, just pointed at a much bigger dataset.

Because it's just an appview, others can (and do) exist over the same records, for example: Blacksky runs its own appview over app.bsky records and is working toward full-network coverage. Others existed before; Zeppelin ran full-network before being decommissioned (suggesting possible != sustainable).

Technically, there are also clients and clients maybe aren't classed as appviews (e.g. Anisota, deer.social) and things like PDSls can show you any repo on any PDS with no index in between. Clients seem very common, but full-network indexes seem less so.

So if Bluesky PBC went away, my records would survive, and my website would keep building, but my notes would no longer appear on Bluesky, and I guess any likes I get on Bluesky would disappear from my counts.

Bluesky-dependent? app.bsky.* definitely is, but community lexicons aren’t. The protocol layer is less and less so.

The schemas: lexicons

app.bsky.feed.post isn't the official atproto post format; an official format doesn't really exist. It's Bluesky's post format in their namespace, and they govern it. Anyone can build on it, but its evolution is owned by Bluesky PBC.

There are many more lexicons in other namespaces: site.standard is designed & owned by three independent platforms as a shared lexicon for longform publishing. So a post published once is readable across all of their readers (and anyone else's reader). And interestingly, the Bluesky app now renders previews of standard.site links, which flips the dependency!

You can also just make your own lexicons. I made some for this website (dev.bekapod.project, dev.bekapod.changelog). None of them have any dependency on Bluesky's schemas, it rests more on com.atproto.*, the foundational parts of which (the repository and sync protocol) are being transferred to IETF and a WG has been formally approved.

Bluesky-dependent? app.bsky.* definitely is but community lexicons are not. The protocol layer is decreasingly so.

So what would actually break for me?

If Bluesky PBC went away tomorrow:

• My handle - still works.
• My DID - maybe a bit awkward. I own the keys, and the directory read replicas would still exist, though governance independence is still in progress.
• My data - still there.
• My notes - still there, although they use Bluesky's lexicon. My dependency is on a schema having a maintainer.
• My "reach" – sort of works? I’d still show up in the wider ATmosphere (standard.site readers, independent appviews) as long as there’s a relay. My Bluesky followers might not see my stuff until someone else’s full-network app.bsky index gets big enough and people move over.
• My own lexicons - still work. Custom lexicons on my own PDS never touch Bluesky's infra to begin with.

I think this helps with my uncertainty. The ATmosphere depends on Bluesky PBC about as much as my stuff runs through the Bluesky app. Storage, identity, publishing, and all the new apps with their own lexicons and appviews seem to survive just fine.

But things seem to be heading the right way, which matters as much as where we are now. If I’d looked at this a year ago, it probably would’ve felt a bit gloomier.

If you want to cut any Bluesky dependencies (for whatever reason, I’m not saying you should), the easiest wins (depending on your comfort level) are using your own domain as your handle and putting your own keys on your DID.