Menu
Menu
Superbloom

Entering the Atmosphere

I went to ATmosphereConf 2026 in Vancouver, not really knowing what to expect. I assumed ATProto and “the Atmosphere” were just Bluesky, but decentralized — I was very wrong

I came away with a list of design problems I hadn’t thought to ask before, and others I hadn’t imagined could be solved. In hindsight, that makes sense — many of the assumptions shaping today’s social platforms were baked in long before ATProto existed.

What feels most interesting now isn’t necessarily what’s already been built in the Atmosphere (much of which intentionally mirrors familiar Web 2.0 experiences), but what the protocol’s underlying primitives make possible to design in the future.

ATProto Primitives

ATProto’s base layer, built on personal data repositories and federated networking, is often described as analogous to the open web. Just as anyone with a computer and an IP address can permissionlessly host a website, anyone can run a Personal Data Server (PDS) and participate in the network.

The key inversion, though, is that the web is location-addressed: data lives at a URL tied to a server. ATProto is identity-addressed: data lives at an at://username/… URI tied to a person rather than a machine.

The protocol also has a two-layer architecture. One layer governs “speech” with the servers, repositories, and federated infrastructure where people publish and store data. In theory, anyone can participate by running their own infrastructure, much like hosting a website on the open web.

The second layer governs “reach”, which relays, feed generators, and other indexing and discovery services that determine how content is surfaced and distributed across the network. T

hese systems function somewhat like search engines or recommendation layers, shaping visibility rather than hosting the underlying data itself. Some of the key primitives powering this include:

  • Decentralized Identitifiers (DIDs): not a login, a persistent cryptographic identity you can digitally carry around. It’s your handle, your relationships, your history, which potentially one could issue for themselves.
  • Signed Records: tamper-evident, self-authenticating data owned by the creator. Our data carries proof of who made it wherever it travels with provenance.
  • Labels: composable, subscribable, multi-party metadata on any content, meaning anyone can annotate anything, and users can choose whose annotations they trust.
  • The Firehose: a real-time stream of all public activity as a raw signal, and users can decide what to listen to. This is what makes third-party apps and new kinds of research and moderation tools possible.
  • Lexicons: synonymous with open schemas, they can be any record type, defined and queryable by anyone. This includes posts, mentions, and likes, as well as scientific papers, code packages, journalist bylines, and moderation votes.
  • AppViews: different “lenses” over the same underlying data, and what people may miss at first is that Bluesky is just one AppView. A science publishing tool is another. A newsroom feed aggregator is another.

Open Science in the Atmosphere

During the workshops I attended on the Open Science track, something clicked, and it wasn’t just one product per se. It was the realization that it was not just lexicons but any record type–a specimen observation, a dataset, a method–defined by anyone, queryable by anyone.

It was my first real encounter with modular science: the idea that research doesn’t have to take the form of a single, monolithic paper, but can instead be broken into smaller, interoperable pieces, each independently citable. It brought clarity to a shift that has been quietly unfolding in science for some time.

But scientific credibility currently resides in journals, where publishers like Nature wield immense power to decide what matters and what doesn’t. The data, citation record, and reputation: all of it accrues inside systems the researcher doesn’t own or control.

Presenters made the point that reproducibility and citation have become afterthoughts bolted onto the publishing workflow that hasn’t fundamentally changed in decades. The epidemic of “sloppification” flooding preprint servers due to the use of LLMs is, of course, hard to ignore. The infrastructure of scientific credibility is captured and inseparable from the platforms that host it, as is the case with journalist credibility.

This is why atproto.science is so provocative to me. The idea that a researcher’s DID could function as a persistent scholarly identity is a new thing. A researcher’s contributions and citations that are now owned by an institution or a publisher would instead be theirs.

And notably, they could use something like Octosphere or Layers, which leverage labels for disaggregated peer review or layered annotations from their trusted communities across various scientific domains.

At Atmosphere, there was a lot of discussion around how much was being built, and all these efforts seemed to be answering in different ways the question of how researchers build credibility when credibility itself is decentralized.

Moderation in the Atmosphere

In my opinion, moderation is where ATProto becomes genuinely wondrous and provocative. On most social media platforms, moderation is a black box. Something goes wrong, content disappears, accounts are suspended, and users are left wondering why. The design and operation of governance here is typically mysterious and vague: there’s no architecture for disagreement, no surface for appeals, and most importantly, no way to build something different. We all must abide by the platform’s rules or leave.

Ostensibly, ATProto’s approach is different. Since labels are an open primitive–composable, subscribable, detachable from any single authority–moderation finally becomes a design surface rather than an opaque platform decree from on high. Anyone can run a labeling service. Communities can define their own standards. Users can subscribe to the labelers they trust. So, the question isn’t “what does the platform allow?”, instead it’s “whose judgment do you want to subscribe to?”

Recognizing the possibility to visibilize and empower human moderation became the most exciting thing I witnessed–not necessarily any single product. Blacksky built its building moderation tooling, Acorn, directly on this primitives layer: it’s a tool that lets a small community in the Atmosphere enforce its own norms without needing to build an entire platform to do it.

NPMx was demoing something even more ambitious: a browsing layer that lets you navigate ATProto’s data space with custom views and filters, putting curation control in the hands of the person, not the app. And Bluesky was beta-testing an AI agent, Attie, letting users personalize moderation by describing exactly what they want to see or avoid, eliminating the need for users to write complex code or logic.

What strikes me about all of these projects is that none of them is trying to be the final answer to moderation. They’re experiments in what becomes possible when moderation is infrastructure rather than policy.

The design questions they’re opening up, like “what does a trust subscription feel like?”, “how do you make a labeling service legible to a non-technical user?”, or “how do you balance community norms with individual autonomy?”, are genuinely novel. Designers haven’t had to design for these things before, simply because the architecture didn’t permit it.

Closing thoughts

And so, I came back from the ATmosphere Conference with something I didn’t expect: a renewed sense that the problems with the ecosystem of social media platforms worth working on are actually tractable. They’re not easy, not solved, but approachable–designable—in a way that they weren’t before.

The open science and moderation problems I’ve described converge on many of the same problems from different angles. Each is fundamentally about the relationship between people, content, and trust, and who gets to define the terms of that relationship.

What ATProto does is take that question out of the hands of any single platform and put it into the protocol layer, where it becomes a design problem anyone in an ecosystem of apps can work on and fix.

The community at ATmosphere — researchers, journalists, builders, designers — felt genuinely energized in a way that stood apart from the usual conference dynamic. There was a warmth and sincerity from the outset, shaped in part by how the space was facilitated.

People kept referring to “the atmosphere” as something more than the event or the protocol itself — a shared orientation toward building systems that don’t repeat the mistakes of Web 2.0.

Whether that idealism holds up at scale is still an open question. But the design space it is opening up feels real. I’ll be watching it closely.