Daniel Holmgren, Head of Protocol at Bluesky, gives a short talk at ATmosphereConf Seattle 2025.

I'm going to be talking about atproto ethos, which is essentially the philosophical and aesthetic principles underlying the design of the protocol. So before we get started, my name is Daniel Holmgren. I'm the Head of Protocol here at Bluesky. You can find me on the atmosphere at dholms.xyz, and for the freaks out there, you can find me at this DID.

The title for this talk actually came from a thought I had whenever I saw Martin post this: he said whether something is decentralized or not is a function of the administrative control of different parts of the system, not a function of the network topology. And this just struck me so hard. I was like, yes, this is exactly what we're going for. I actually brought this up to Martin a couple of days ago; he didn't even remember posting it. I'm like, I think about this every week, Martin.

I quoted this and said: this is atproto ethos. And I do think this is very descriptive of the topology and the power dynamics in the network, but what it doesn't quite have is a prescription for how to get there. So this term "atproto ethos" kept coming up in our protocol design questions. We kept coming back to it whenever we were weighing different options. I wanted to take the chance to dissect what that ethos is, the historical influences on the design of the protocol, some of the new things we brought to it, as well as some of the postures we adopt as we are working on the design.

Not all of this was perfectly packaged from the beginning—we had a million false paths, dead ends, and hard debates between team members. Maybe in a future talk we can give the philosophical history of atproto, but today I'm going to give you the nice, clean, packaged version.

I would sort of situate atproto at the center of three movements: the web, the peer-to-peer movement, and—I don’t have a good quick word for this—the world of large distributed systems and data-intensive applications that run the modern web. I didn’t have a good picture for that, so I used the boar from Martin’s book.

We’ll start with the most obvious influence: the web. As I’m sure you all know, the web is an information system for publishing documents over the internet. If you have a static IP address and you have a server, you can host a document. If you have an internet connection and a route to that server, you can fetch that document. The incredible thing about the web—the defining feature—is that it's completely permissionless. That's the only thing you need to publish a document or fetch a document.

Location is also the basis of authority. We layer DNS on top of IP addresses. This sounds obvious, but you know that a document is the thing you got from a server because you talked to that server and it gave you the document. The authority rests in the location you contacted.

This permissionlessness was a radical idea. You didn’t need any central publisher, any central distributor, any certification checklist to say you could publish a document. And if that was the defining governance feature, the defining product feature was the hyperlink. Documents could link to other documents, and specifically they could link across authorities, completely permissionlessly.

The downside is: servers are hard. Not everyone can run one, get a static IP, or configure DNS. So we saw the rise of the modern web—so-called “Web 2.0”—moving from permissionless publishing to platforms. Everything ran on a big server—call it bigsocial.com. These platforms were account-based. You’d register an account. It was extremely easy to post; you didn’t need technical knowledge. You had rich media, dynamic interactions, algorithms to rank content, and so on. I’m not nostalgic for Web 1.0—there’s a lot about the modern web that is great—but something was lost.

Which brings us to the next influence: the peer-to-peer movement. In many ways, this was a response to the centralization of social platforms. The basic question it asked was: Why is there a server in the mix?

If I follow someone, and they want to send me a post, why can't their phone just send it directly to my phone? Can you build a modern social network without a backend? This came from distrust of centralized platforms.

But then you run into problems: what if I’m offline? What if an intermediary modifies the message? So these protocols used public key cryptography to sign messages, making the data self-certifying. They then used content-addressed data so you could fetch objects by hash from anywhere in the network. When it worked, this abstraction was beautiful: location dissolved away.

But phones are smaller than data centers. They can’t store global state, they have battery and CPU constraints, and they can't produce globally consistent views like centralized systems.

Which brings us to the third influence: the rise of large distributed data systems powering the modern web. These had millions or billions of users, real-time dynamic updates, extremely read-heavy workloads, and very high expectations around latency and uptime. Data-intensive applications needed new techniques.

Typical evolutions included splitting reads and writes, decomposing into microservices, embracing eventual consistency, using databases like Cassandra/Scylla, and eventually introducing stream processors like Kafka as the canonical sequence of all writes. Stream processors became the backbone of these architectures: if a service went down, it could catch up; if you needed to rebuild an index, you could replay from the beginning.

This brings me back to atproto ethos: a synthesis of the three movements.

From the web: openness, permissionlessness, interconnected data. From P2P: location-independent, self-certifying data; skepticism of centralization. From large systems: split read/write workloads, microservices, eventual consistency, stream processing.

Now onto the new things atproto introduced.

First: identity-based authority. In contrast to location-based (the web) or content-based (P2P), authority in atproto comes from identity. My account at dhomes.xyz is the primary thing, and it contains the social data. The addressing scheme reflects this.

This gives location-independent data. Every identity resolves to a DID, and the DID resolves to the location of the data and the key material. Identities float on top of the hosting layer and can migrate.

Second: generic hosting separated from application semantics. A PDS sees only CBOR objects—it doesn't know the semantics of posts, likes, images, or anything else. Applications define their own schemas independently. This gives decentralized hosting with centralized product development.

Next, the postures we took. The first is that structure gives you freedom. Atproto is a multi-party, low-coordination network. Without enough structure, you get the tyranny of structurelessness, where nothing can evolve coherently. So the protocol is very structured: canonical CBOR, a deterministic data structure (the MST), constrained hashes and DIDs, and especially Lexicon—the schema system. We chose a schematic rather than semantic approach: instead of trying to interpret ambiguous objects, we make it black-and-white whether something matches a schema.

The second posture is what I call lazy trust. Instead of trying to be trustless (which has costs), we trust services by default but always maintain a credible exit. I trust my PDS and Bluesky, which lets me hoist my signing key into the PDS. But if the PDS goes evil, I can migrate. If the Bluesky app view goes bad, every other app has access to the same open data, and users can move.

Wrapping up: atproto sits at the intersection of the web, peer-to-peer, and modern distributed systems. It introduces identity-based authority and separation of data hosting from application semantics. And it takes a posture of structure and lazy trust with credible exit.

The videos from ATmosphereConf 2025 held in Seattle, Washington, are being republished along with transcripts as part of the process of preparing for ATmosphereConf 2026, taking place March 26th - 29th in Vancouver, Canada.

Follow the conference updates and register to join us!