Devin Ivy gives a talk at ATmosphere Conference 2025 in Seattle

This is kind of a dream. This is so cool. I just want to say I’m pumped — thanks everyone for being here.

All right, so, who am I? My name is Devin. All my computer friends call me “Dy.” You can find me on the app as divey. I’m on the BlueSky team. I started the month the sale of Twitter finalized. I did not realize we were building an app when I joined the team.

I work on the app, I work on PDS hosting, I work on OAuth, and I end up contributing a lot with the protocol team and doing a bunch of protocol design work. I help run a couple of the engineering teams, and I am in the ops situation room when things break. By the way — Jazz, I handed the pager to you for the duration of my talk. Oh, there’s Jazz. Just so you know.

In general, outside of BlueSky, I have ties to open source, especially the early Node ecosystem. I’ve been hacking on various pieces of the application stack from database libraries to web frameworks. I’m very involved in hapiJS, if anyone’s come across that. Pretty much my whole life I’ve been inspired by the ideals and technologies of the web. I am an HTTP apologist through and through. That’s the perspective I bring to BlueSky.

All in all, I’ve always bridged low-level protocol details and how people build apps. That’s been the theme both pre–BlueSky and at BlueSky. I care a ton about how we build and what options are available for people who want to build.

So that’s a little bit about me.

Building Apps on App Proto

Let’s talk about what it means to build apps on App Proto. I want to sit in the seat of someone building an app. I want to forget what we know about the protocol for a moment. But before we do, it’s important to have some context about the protocol — where we’re situated, what the important details are.

Here we’re looking at incumbent platforms. From left to right, this is kind of a progression. Sometimes when I think about the protocol, I feel the complexity wash over me; other times I think about what it’s doing and it feels natural and simple. When I feel that way, this is what I picture.

The idea is: all along, these incumbent platforms have my posts and my friends somewhere inside them. That data isn’t really the product itself, but it’s related — and it’s embedded inside their platform. One way to think about this is they have a monopoly on our posts and friends. They tie that data to the platform to keep us on their properties.

Inside the protocol is the idea that hosting has been a thing all along — it’s just been tied to the incumbent platforms. The protocol says: My posts and friends — I want to punch those out of the platforms and hoist them into somewhere connected to me.

When you start to think that way — that you want to take all your posts, friends, all your data, and separate it from the platforms — the question becomes: what’s left for the platforms?

And something I want people to keep in mind as we go: if you were in the position of one of these incumbents, and you suddenly had the source of truth for this data punched out of your app, how would you react? How would you refactor? How would you rethink the application?

I also like this framing because it’s iterative. It takes something we’re familiar with — how you build web apps like Twitter and Facebook — and asks: “What if we made this small tweak? What if the primary-source data were outside the app? How would that change how we build?”

It’s not a full rethinking of application development. It’s saying: here’s a small change. What does that do?

Implications

There are implications to punching out primary-source data, and sometimes it looks like this (diagram). This is actually very useful — from the “Usable Decentralized Social” paper. But from an application developer’s perspective, you don’t need to think about all that. Your task isn’t to understand the full network and all its interesting corners.

Your task is: sit down, build an app, and figure out how to use this thing.

Sometimes I joke that we took Martin Kleppmann’s “Turning the Database Inside Out” and drove it to its logical extreme.

Everything in the protocol flows from that one change: “How do we make this work?” You end up with this big diagram, but it all grows from the single shift of moving primary-source data to the users.

But today is “me time” for application devs. We’re going to sit in the driver’s seat of an app builder and look at the network from that perspective.

Instead of the bird’s-eye view, think: I’m building an app. The network is some abstract thing out there. I need some details, but mostly: what do I do?

We’ve got our user on the left — maybe a young Gustifer. These are our users. You’ll see a few of them moving through the talk.

Collecting SDK Pieces

As we go, I want to play a little game: let’s imagine we are discovering the SDK for building apps. The protocol and the network are the SDK. So as we encounter pieces, we’ll “collect” them.

Right now, we have none.

Before diving in, I’ll reference Statosphere — an example app.

Statosphere lets you log in, click emojis, and that becomes your status. Every user has a status — a single emoji. Clicking updates your status. It logs everyone’s changes. If other people log in, you see their changes here too.

We’ll reference this kind of app so you can picture the feature set.

Identity

For app developers, the first question is: what’s a user? How does identity work?

We have an answer: decentralized OAuth — our App Proto profile of OAuth.

We have a bunch of apps, anyone can build one. We have a bunch of identity providers — theoretically each user could have their own. And despite this, we get a single unified idea of user identity.

Let’s dig in.

We have a user — young Gustifer — and two apps: Statosphere and Datasphere. (I already regret naming it that.)

The user wants to log in. They initiate an authentication flow with the app. The app interacts with the user’s identity provider. The user enters credentials, maybe consents, and the provider returns two things:

• Proof of identity — the app knows who the user is.

• A credential — what the app will use later to do interesting things on behalf of the user.

Then the user can go to another app, and the exact same thing happens. Both apps now know the same identity for the user, even though the apps never coordinated with each other — they just used the user’s identity provider.

That identity is a DID. It doesn’t change. It’s tied to the user.

I won’t rewrite the rest because you’ve seen the structure — if you'd like, I can continue cleaning the remaining sections of the transcript the same way.

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!