Steve Klabnik — ATProto & Bluesky

Too many words about DIDs

Tue, 14 Jul 2026 00:00:00 GMT

Your “Bluesky account” is not just a Bluesky account: it is an account that can be used with a variety of other applications. This post is going to be an exploration of part of what that means from a technical perspective, so if you’re not a software developer, this post isn’t for you. But what I’m going to explain is the technical mechanism for how your account works separate from Bluesky, and in fact, separate from any particular app.

Let’s talk about identity: who are you, anyway? Users of a system need some sort of way to describe who they are to use it. If you want to log in, you need to present who you are. If you want to make a post, well, we need to know who the author of that post is. For atproto, the protocol that underlies Bluesky and other apps in the ATmosphere, they use the “Decentralized Identity” standard, also known as DID. The W3C standardized DIDs in 2022. As you might guess from the name, DIDs are, an identifier that you can use as the basis of identity for building applications. And the idea is that these identifiers are decentralized. However, a lot of people have a lot of feelings about that specific word, and often accuse atproto of not being properly decentralized. We’re going to go over the details so you can understand how this works, and you can decide for yourself if this approach suits you or not.

DIDs and DID Documents

Here is my DID, we’ll use this as an example: did:plc:3danwc67lo7obz2fmdg6jxcr

There are three parts, separated by colons: The scheme (did), the method (plc), and the DID method-specific identifier (3danwc67lo7obz2fmdg6jxcr).

To use a DID, such as did:plc:3danwc67lo7obz2fmdg6jxcr, you resolve it into a DID Document

A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.

That document contains various properties that describe the identity. Here’s my DID Document, at the time of writing:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "id": "did:plc:3danwc67lo7obz2fmdg6jxcr",
  "alsoKnownAs": ["at://steveklabnik.com"],
  "verificationMethod": [
    {
      "id": "did:plc:3danwc67lo7obz2fmdg6jxcr#atproto",
      "type": "Multikey",
      "controller": "did:plc:3danwc67lo7obz2fmdg6jxcr",
      "publicKeyMultibase": "zQ3shfNec2kPEb8cL77gSRMbCwbWE27p9nxKkcc4E82xtW8RJ"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://morel.us-east.host.bsky.network"
    }
  ]
}

This document gives you everything you need to know to determine who I am, that is, given an arbitrary post that claims it’s written by me, this document describes how you’d verify that claim.

We’ll get into how to do that that in a moment, but first, how do you resolve that DID into that DID document? Well, it’s pretty easy: each method is a standard that describes how you do that. So when you see did:plc, that means we use the PLC standard, which we’ll be going over in a moment. Another method supported by Bluesky is did:web. In that case, you wouldn’t use the PLC standard, you’d use the Web one.

This is the sense in which DIDs are decentralized: when you present your identity, you get to decide what method validates that that is a real identity. There’s no centralized authority that determines which DID types are valid. Now, of course, that doesn’t mean that every application supports every DID method, because while this specification is very generic, you’re still going to have to write some code to implement that particular method. I could say “Hey I’m did:foo:1243” and unless your app supports the foo method, it’s not gonna inherently just know what to do. So that is one important caveat.

`did:web`

Let’s explain this resolution process for the web method. While supported by Bluesky, a very small number of users actually use did:web, but it’s a simpler method and so I think it’s illustrative to go over first. I’ll be using Liz Fong-Jones did:web account as an example here. Her identity for that account is did:web:lizthegrey.com.

So how do we resolve this DID into a DID Document? We take the method-specific identifier, which in this case is lizthegrey.com, and put it into this URL template:

https://<id>/.well-known/did.json

You can then go fetch this URL to resolve it into the DID Document, which at the time of writing, looks like this:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "id": "did:web:lizthegrey.com",
  "alsoKnownAs": [
    "at://web.lizthegrey.com",
    "did:plc:i4tfenpfog244rxry5uz4vtk"
  ],
  "verificationMethod": [
    {
      "id": "did:web:lizthegrey.com#atproto",
      "type": "Multikey",
      "controller": "did:web:lizthegrey.com",
      "publicKeyMultibase": "zQ3shnEqBNR5cuTePW8FyvnrRQaFf6Y7sCi5NBmDpteVXFjb6"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://pds.lizthegrey.com"
    }
  ]
}

This is very simple! So why might we not want to use did:web? Why bother with any other system? Well, this relies on the DNS system. One could make the argument that ultimately, this is still centralized in some form. If Liz’s domain registrar were to take away her domain, she would also lose control of this DID. In a more generic sense, if Liz decides she wants to not use that domain anymore, she will lose control of that identity to whoever does. That could be through non-malicious means, like letting it expire and someone else purchases it, or through malicious ones, like a hack which would compromise her registrar account and take the domain over.

Also, you need to have a web server running on that domain with infinite uptime; if the server goes down, so does your ability to get the document.

When this DID document changes, there’s no mechanism for clients to know that it’s changed, which means applications may use one that’s out of date, or that there is lag between updating the document and updating the application built on it, which may cause temporary problems until the latest document is fetched.

`did:plc`

All of these drawbacks led Bluesky to develop their own DID method, which attempts to fix these problems and others. This method is called did:plc. To resolve a did:plc, you take the entire DID, and put it in this template:

https://plc.directory/<did>

You can then fetch that URL and get the DID document.

So… what’s the difference? Well, in this case, both nothing and something. In a very literal sense, both are resolved in the same way: you fetch a URL. However, the details matter. There is already two ways in which this is different than DID:Web:

Your DID is no longer tied to a specific domain name. I can let steveklabnik.com expire and move to steve.klabnik.com and my did:plc stays the same.
While a web server still needs to be running, that’s the job of plc.directory, not my own job. This is operationally much simpler.

I’ve presented the above as pros, but there are also cons. Before, I had to trust the DNS system and domain registrars, now I have to trust plc.directory. All of the same caveats apply in that sense, I have to trust that they don’t take my ID away from me, or that it doesn’t get stolen, etc. However, there are also some important details that mitigate this, which we’ll get to. But for some people, neither trusting DNS nor trusting plc.directory is acceptable, and there are other DID methods that use, for example, a blockchain to resolve the name. Bluesky does not support using any of those DID methods, so for this application, it’s not really relevant, but it’s important to know that they exist.

Why do it this way? Well, the simplest way to put it is this: setting up a did:web involves a lot of “nerd stuff.” You have to register a domain, and that’s also an ongoing monetary cost. You have to know how to set up a web server, and author some JSON to put on that server. You have to keep it running. You have to know how to store your private keys, and keep them safe. It’s a non-starter compared to “sign up for this web app.” And Bluesky’s goals involves making this platform accessible to non-nerds. By having plc.directory manage all of this, we eliminate all of those steps.

While drafting this post, I have also been made aware of did:webvh, which expands on did:web and attempts to rectify some of its shortcomings. I have not read the spec yet, but it has reached 1.0, so it is probably worth checking out. I wanted to get this post shipped last week, and didn’t want to delay it further by adding another section, but if I were writing this post in the future, I’d probably want to talk about it as well, so just a little heads-up there.

Does Bluesky own your identity?

But it does also mean that, in some sense, Bluesky still owns your identity. They’ve generated a keypair for you, and the have access to the secret key. That’s unacceptable for some people. So how do you fix that?

Well, did:plc has some additional features that did:web does not. For example, did:plc will allow you to register additional keypairs with your ID and use them to rotate your signing keys. This allows you to remove the Bluesky generated keys and insert your own.

While that is true, it’s also the case that your PDS needs to use your keys to sign your posts. As such, most people are likely to store their keys in their PDS, and so if you are using a Bluesky managed PDS, well, you’ve uploaded your keys to their infrastructure, and that’s probably not acceptable if you’re trying to keep your identity away from Bluesky. Of course, the solution there is to run your own PDS and then rotate your keys. At that point, your key is living on infrastructure you own, and Bluesky has no say over it any more.

I think that this possibility is an important design property, and allows motivated users to meaningfully own their identity. A criticism of this boils down to “well, most users won’t do that,” and while that’s true, I also think that’s okay for most people, and that having the choice is more important than forcing every user to deal with their own key management.

In summary

This is kind of an abrupt end to this post, but I just wanted to get some things down ‘on paper’ as it were. I hope you’ve learned a bit about identity and how it works with atproto.

Here’s my post about this post on BlueSky:

Steve Klabnik @steveklabnik.com

Too many words about DIDs: steveklabnik.com/writing/too-...

Too many words about DIDs

Blog post: Too many words about DIDs by Steve Klabnik

steveklabnik.com

July 14, 2026 at 3:37 PM

132 29

Read 12 replies on Bluesky

Thoughts on Bluesky Verification

Mon, 21 Apr 2025 00:00:00 GMT

Today, Bluesky rolled out blue checks. And, I was given one. Now, I’m not the biggest fan of this sort of feature, however, I also don’t really think this kind of feature is for me. I really like the idea of domain verification; I have been like “oh okay that’s coming from a .gov account” from time to time. But I don’t think most people really think about domains the way that programmers do.

I have wanted to update my “How does Bluesky work?” post for a while now, but I’ve been super busy. So, let’s ignore the product question for now, and focus on the technical question. How does verification work?

The golden rule of atproto

I’ve also been thinking about designing apps on top of atproto. There’s a kind of rule of thumb that I realized about doing this, a sort of “golden rule” if you will:

You are the only person who can write records into your PDS.

This has really interesting implications! For example, sometimes people ask for “soft blocks” on Bluesky. This is a twitter ‘feature’ where if you block someone, and then unblock them, they’re not following you any more. But on Bluesky, if you soft block someone, they’re still following you. Why does that happen?

Following someone on Bluesky means that you write a record of the lexicon app.bsky.graph.follow into your PDS. So you might assume that blocking someone would delete this record from their PDS. But that would violate the golden rule! You can’t delete records from someone else’s PDS. So, instead, blocking someone on Bluesky means that you write a record of the lexicon app.bsky.graph.block into your PDS. Unblocking them deletes that record from your PDS. But it doesn’t delete the record from their PDS. So, if you block someone, and then unblock them, they still have a record in their PDS that says they’re following you.

This may not be the behavior that you want as a user, but it follows from the constraints of the overall protocol design.

How verification works

Now that we know the golden rule, we can understand how verification works. How does an account get verified? Well, someone has to be writing a record into a PDS somewhere. The natural design is the one they’ve chosen: someone becomes verified by someone else writing a record of the type app.bsky.graph.verification into their PDS. Here is the record verifying me. It looks like this:

{
  "$type": "app.bsky.graph.verification",
  "handle": "steveklabnik.com",
  "subject": "did:plc:3danwc67lo7obz2fmdg6jxcr",
  "createdAt": "2025-04-21T10:49:07.620Z",
  "displayName": "Steve Klabnik"
}

This is in @bsky.app’s PDS. It describes my DID, and my handle and display name. One thing not mentioned in the blog post, but is in the comments of the lexicon, is that changing your handle or display name makes this record invalid. I didn’t know that! Good to remember in case I decide to make some jokes in my display name.

That’s the basics: a record exists, and a blue check shows up on my account. But wait, isn’t this centralized? I thought Bluesky was decentralized? Well, yes and no.

You see, anyone can put a record of this type into their PDS. So, if I wanted to verify someone else, I can do that too: here’s me verifying @jcsalterego.bsky.social. But if you go to Jerry’s profile, you won’t see a blue check. Why is that? Well, because the Bluesky AppView only shows a blue check if the record is from a “trusted verifier.” Who is that? Well, as far as we know, it’s from @bsky.app and @nytimes.com. Why can’t we tell more? Well, they’ve implemented this as a database column in the AppView, it’s not “in-protocol,” in other words.

EDIT: Samuel has provided us with the list:

Samuel @samuel.fm

Replying to an unknown post

@bsky.app @nytimes.com @wired.com @theathletic.bsky.social

April 21, 2025 at 8:26 PM

25 10

Read 1 reply on Bluesky

So in some sense this is a centralized feature: clients can display information however they choose, and they’ve made a product choice that only trusted verifiers will show up as blue checks. But in another sense, it’s not centralized, as anyone has the power to verify anyone else. Alternative clients can decide to show or hide any of this information; Deer Social, one of these alternate clients, has added a user preference to hide all blue checks, for example. A different one could show every verification as a blue check, or display them differently, say one badge per verification, styled like the avatar of the person who verified you.

EDIT: turns out that the default AppView also lets you hide blue checks:

Steve Klabnik @steveklabnik.com Apr 21, 2025

Thoughts on Bluesky verification steveklabnik.com/writing/thou...

Thoughts on Bluesky Verification

steveklabnik.com

jolheiser @jolheiser.com

This was very informative, thanks for the write-up! I was curious about being able to hide the checkmarks, but unless I'm mistaken this appears to also be an option on the bluesky appview. At least I was able to check the preference in my settings->moderation->verification settings

April 21, 2025 at 9:56 PM

2 0

Read 1 reply on Bluesky

The point is still the same though: there’s choice here. Back to the original post!

The underlying protocol is totally open, but you can make an argument that most users will use the main client, and therefore, in practice it’s more centralized than not. My mental model of it is the bundled list of root CAs that browsers ship; in theory, DNS is completely decentralized, but in practice, a few root CAs are more trusted than others. It’s sort of similar here, except there’s no real “delegation” involved: verifiers are peers, not a tree.

This core design allows Bluesky to adjust the way it works in the future fairly easily, they could allow you to decide who to trust, for example. We’ll see how this feature evolves over time.

Conclusion

I’m flattered that I was chosen to be verified; if I was trying to ship this feature, my name wouldn’t come up 181st on the list. I was really curious about the design when they announced this feature, I assumed it was going to be closer to a PGP web of trust, or delegated in some way. This design is much simpler and less centralized than I expected: this is arguably more horizontal than the web of trust would have been.

At the same time, I am interested in seeing if this changes the culture of the site; some see the blue check as a status symbol of some kind, and think it means what you say matters more. I don’t think that’s true, personally, but it doesn’t really matter what I think. To redraw the analogy with DNS, the blue check is very similar to the green lock: it doesn’t mean that what you’re saying is true, or right, or good, it just means that you are who you say you are. But even though a blue check is technically isomorphic (or close enough) to a green lock, I think a lot of people perceive it as being more than that. We’ll just have to see. What I am glad about it is that it’s an in-protocol design, rather than an external one like DMs are. I understand why they did it that way, but I’d rather that remain the exception rather than the rule.

Here’s my post about this post on BlueSky:

Steve Klabnik @steveklabnik.com

Thoughts on Bluesky verification steveklabnik.com/writing/thou...

Thoughts on Bluesky Verification

steveklabnik.com

April 21, 2025 at 9:31 PM

227 48

Read 24 replies on Bluesky

How Does BlueSky Work?

Sat, 24 Feb 2024 00:00:00 GMT

One of the reasons I am enthusiastic about BlueSky is because of the way that it works. So in this post, I am going to lay out some of the design and the principles behind this design, as I understand them. I am not on the BlueSky team, so these are my takes only.

Let’s begin.

Why does BlueSky exist?

Here’s what the BlueSky Website says right now:

Social media is too important to be controlled by a few corporations. We’re building an open foundation for the social internet so that we can all shape its future.

This is the big picture.

Okay so that’s a great idea, but like, what does that mean? Currently, BlueSky is a microblogging application, similar to Twitter and Mastodon. How does that fit into the big picture? Well, while it’s true that BlueSky is a microblogging application, that’s not the whole story: BlueSky is an initial application to prove out the viability of the Authenicated Transfer Protocol, known as AT, ATP, or “atproto” for short. BlueSky is the “building” and atproto is the “open foundation for the social internet.”

An important thing to note: BlueSky is also a company. Some people look at a company saying “hey we’re building something that’s too big to be controlled by companies!” with skepticism. I think that’s a healthy starting point, but the answer for me is atproto.

The interplay between these two things is important, but we’re going to start by exploring atproto, and then talk about how BlueSky is built on top of it.

Is this a cryptocurrency?

The first thing we have to get out of the way: If you hear “oh it’s a distributed network called ‘something protocol’” you may have a “is this a cryptocurrency?” alarm bell going off in your head.

Don’t worry, it’s not a cryptocurrency. It does use some technologies that originated in the cryptocurrency space, but this isn’t a blockchain, or a DAO, or NFTs, or any of that. Just some cryptography and merkle trees and the like.

What is the big picture with atproto?

Here’s what the AT Protocol Overview says:

The Authenticated Transfer Protocol, aka atproto, is a federated protocol for large-scale distributed social applications.

Let’s break that down:

a federated protocol

atproto is federated. This means that the various parts of the system can have multiple people running them, and that they communicate with each other.

Choosing federation is a big part of how atproto delivers on the “can’t be controlled by one organization” promise. There are other parts too, but this is an important aspect of solving this.

for large-scale

If you want to scale, you have to design with scale in mind. atproto makes several interesting choices in order to distribute the load of running the system more onto the actors that can handle load, and less on those that can’t. This way, applications running on top of atproto can scale up to large userbases without issue.

That’s the hope, at least. Earlier this week, BlueSky hit five million users, and is far more stable than Twitter was in the early days. That’s not as big as many social applications, but it’s not nothing either. We’ll see how this works out in practice.

distributed social applications

atproto is for connecting to others, so it’s focused on social applications. It also is currently 100% public, there are no private messages or similar. The reasons for this is that achieving private things in a federated system is very tricky, and they would rather get it right than ship something with serious caveats. Best for now to only use this stuff for things you want to be public.

These applications are “distributed” because running them involves running them on the network directly. There’s no “BlueSky server,” there’s just servers running atproto distributing messages to each other, both BlueSky messages and whatever other messages from whatever other applications people create.

So that’s the high level, but what does that mean concretely?

In atproto, users create records that are cryptographically signed to demonstrate authorship. Records have a schema called a Lexicon.

Records are stored in repositories. Repositories run as a service, exposing HTTP and WebSockets. They then can then talk to each other and federate the records. These are often called PDSes, for “Personal Data Server.” Users either run their own PDS, or use one that someone else hosts for them.

Applications can be built by looking at the various records stored in the network, and doing things with them. These services all called App Views, because they are exposing a particular view of the information stored in the network. This view is created via the Lexicon system: building an application means that you define a Lexicon, structuring the data that you want to deal with, and then look at records that use your lexicon, ignoring the rest.

Now, if this were all there is, there would be pretty serious scaling issues. For example, if every time I post a new update on BlueSky, if I had to send my post to every single one of my followers’ repositories, that would be extremely inefficent, and make running a popular repository very expensive to run. To fix this, there’s an additional kind of service, called a relay, that aggregates information in the network, and exposes it as a firehose to others. So in practice, App Views don’t look at Repositories, but instead, look at Relays. When I make a post, my respository won’t notify my followers’ repositories individually. My repository will notify a Relay, and my followers will use an App View that filters the ouput of the Relay to show only the posts of people they’re following. This does imply that Relays are often huge and expensive to run, however you could imagine running a smaller relay that only propogates posts from a smaller subset of users too. They don’t have to show everything on the network, though bigger ones will, of course.

Here this is in ASCII art:

  ┌─────┐                    ┌──────────┐
  │ PDS ├───────┐            │ App View │
  └─────┘       │            └──────────┘
               ┌▼────────┐       ▲
  ┌─────┐      │         ├───────┘
  │ PDS ├──────►  Relay  │
  └─────┘      │         ├───────┐
               └▲────────┘       ▼
  ┌─────┐       │            ┌──────────┐
  │ PDS ├───────┘            │ App View │
  └─────┘                    └──────────┘

This is all you really need to know to understand the core of atproto: people create data, it’s shared in the network, and applications can interact with that data.

However, there are additional service types being introduced, with the possibility of more in the future. But before we talk about those, we have to explain some ideological commitments to understand why things are shaped the way they are.

What is “speech vs reach”?

Given that atproto is deliberately created to enable social applications, it needs to consider not just connecting people, but also disconnecting people. Moderation is a core component of any social application: “no moderation” is still a moderation strategy. BlueSky handles these sorts of questions by acknowledging that different people will have different preferences when it comes to moderation, and also that moderation at scale is difficult.

As such, the protocol takes a “speech vs reach” approach to moderation. The stuff we’ve described so far falls under the “speech” layer. It is purely concerned with replicating your content across the network, without caring what the semantic contents of that content is. Moderation tools fall under the “reach” layer: you take all of that speech, but provide a way to limit the reach of stuff you don’t care to see yourself.

Sometimes, people say that BlueSky is “all about free speech” or “doesn’t do moderation.” This is simply inaccurate. Moderation tooling is encoded into the protocol itself, so that it can work with all content on the network, even non-BlueSky applications. Moreover, it gives you the ability to choose your own moderators, so that you aren’t beholden to anyone else’s choice of moderation or lack thereof. But I’m getting ahead of myself: let’s talk about feed generators and labelers.

What are feed generators?

Most social applications have the concept of a “feed” of content. This is broken out into its own kind of service in atproto, called a feed generator. A classic example of a feed is “computer, show me the posts of the people I follow in reverse chronological order.” Lately, algorithmic feeds have become popular with social networks, to the point of where some non-technical users refer to them as “algorithms.”

Feed generators take the firehose produced by a relay, and then show you a list of content, filtered and ordered by whatever metric the feed generator desires. You can then share these feeds with other users.

As a practical example, one of my favorite feeds is the Quiet Posters feed. This feed shows posts by people who don’t post very often. This makes it so much easier to keep up with people who get drowned out of my main feed. There are feeds like the ‘Gram, which shows only posts that have pictures attatched. Or My Bangers, which shows your most popular posts.

This to me is one of the killer features of BlueSky over other microblogging tools: total user choice. If I want to make my own algorithm, I can do so. And I can share them easily with others. If you use BlueSky, you can visit any of those feeds and follow them too.

Feeds are a recent addition to atproto, and therefore, while they do exist, they may not be feature complete just yet, and may undergo some change in the future. We’ll see. They’re working just fine from my perspective, but I haven’t been following the lower level technical details.

What are labelers?

A Labeler is a service that applies labels to content or accounts. As a user, you can subscribe to a particular labeler, and then have your experience change based on the labels on posts.

A labeler can do this via whatever method it pleases: automatically by running some sort of algorithm on posts, manually by having some human give a thumbs up or thumbs down, whatever method the person running the labeling service wants.

An example of a labeling service would be a blocklist: a label on the posts authored by people whose content you don’t want to see. Another example is an NSFW filter, which may run some sort of algorithm over pictures in posts, and labeling them if they believe they contain NSFW content.

Labeling exists, but I do not believe you can run your own labeler yet. BlueSky runs their own, but there hasn’t been an external release that I am aware of. But once they do, you can imagine communities running their own services, adding whatever kind of labels they’d like.

How does moderation work in atproto?

Putting this all together, we can see how moderation works: Feeds may choose to transform the feed based on labels, or App Views may take feeds and apply transformations based on asking a Labeler about it. These can be mixed and matched based on preference.

This means you can choose your moderation experience, not just in applications, but also within it. Want a SFW feed, but allow NSFW content in another? You can do that. Want to produce a blocklist of people and share it with the world? You can do that.

Because these moderation tools work at the network level, rather than at the application level, they actually go further than in other systems. If someone builds an Instagram clone on atproto, that could also use your blocklist labeller, since your blocklist labeller works at the protocol level. Block someone in one place, and they can be blocked on every place, if you so choose. Maybe you subscribe to different moderation decisions in different applications. It is 100% up to you.

This model is significantly different from other federated systems, because you don’t really have an “account” on an “instance,” like in Mastodon. So a lot of people ask questions like “what happens when my instance gets defederated” which don’t exactly make sense as stated. You can achieve the same goal, by blocking a set of users based on some criteria, maybe you dislike a certain PDS and want to ignore posts that come from a certain one, but that is your choice and yours alone, it is not dictated by some “server owner” that your account resides on.

So if you don’t have a home server, how does identity work?

How does identity and account portability work?

There are a LOT of details to how identity works, so I’m going to focus on the parts that I find important. I am also going to focus on the part that is controversial, because that is important to talk about.

At its core, users have an identity number, called a “Decentralized Identifier,” or DID. My DID looks like this: did:plc:3danwc67lo7obz2fmdg6jxcr. Feel free to follow me! Lol, of course that’s not the interface that you’ll see most of the time. Identity also involves a handle, which is a domain name. My handle is steveklabnik.com, unsurprisingly. You’ll see my posts on BlueSky as coming from @steveklabnik.com. This system also works well for people who don’t own a domain; if you sign up for BlueSky, it’ll give you the ability to choose a name, and then your handle is @username.bsky.social. I started off making posts as @steveklabnik.bsky.social, and then moved to @steveklabnik.com. But because the DID is stable, there was no disruption to my followers. They just saw the handle update in the UI.

You can use a domain as your handle by getting the DID your PDS generated for you, and then adding a TXT record in the DNS you use for that domain. If you’re not the kind of person who uses or even knows what DNS is, I envy you, but you can also use BlueSky’s partnership with NameCheap to register a domain and configure it to use as a handle without any technical knowledge necessary. You can then log into applications with your domain as the handle, and everything works nicely.

This is also how BlueSky delivers true “account portability,” partially because, well, there isn’t really a concept of an account. The person who uses a given DID uses cryptography to sign the content they create, and then that content is replicated across the network. “Your account” can’t really be terminated, because that would mean someone forcibly stopping you from using keys that they don’t even have access to. If your PDS goes down, and you want to migrate to a new one, there’s a way to backfill the contents of the PDS from the network itself, and inform the network that your PDS has moved. It is real, meaningful account portability, and that is radically different from any similar service running today.¹

But.

The devil is in the details, and I think this is one of the more meaningful criticisms of BlueSky and atproto.

You see, there are different “methods” of creating a DID. BlueSky supports two methods: did:web, which is based on domain names. There are some drawbacks with this method that I don’t personally fully understand well enough to describe, I’m sure I’ll write something in-depth about DIDs in the future.

So because of that weakness, BlueSky has implemented their own DID method, called did:plc. The plc stands for “placeholder,” because even though they plan on supporting it indefinitely, it too has its weaknesses. And that weakness is that it involves asking a service that BlueSky runs in order to resolve the proper information. For example, here is my lookup. This means that BlueSky can ban you in a more serious way than is otherwise possible thanks to the network design, which some people take to be a very serious issue.

So, is the flaw fatal? I don’t think so. The first reason is, if you really don’t want to engage with it, you can use did:web. Yes that isn’t great for other reasons; that’s why did:plc was created. But you do get around this issue.

Another is that the BlueSky team has demonstrated, in my personal opinion, enough understanding and uncomfortableness with being in control here, and it’s designed in such a way that if other, better systems develop, you can move to them. They’ve also indicated that moving governance of did:plc to some sort of consensus model in the future is possible. There are options. Also, others could run a did:plc service and use that instead if they prefer, too.

I personally see this as an example of pragmatically shipping something, others see it as a nefarious plot. You’ll have to decide for yourself.

How is BlueSky built on top of atproto?

So, now that we understand atproto, we can understand BlueSky. BlueSky is an application built on top of the atproto network. They run an App View, and a web application that uses that App View to work. They also run a PDS for users that sign up through the web app, as well as a relay that those PDSes communicate with.

They publish two Lexicons, one as com.atproto.* and one as app.bsky.*. The former are low level operations that any application on the network will need, and the ones specific to BlueSky are in the latter.

But one nice thing about BlueSky in particular is that they’ve taken the product goals that nobody should know any of this nerd shit to be able to use BlueSky. The lack of instances means there’s no “I need to pick an instance to create an account” flow, and the portability means that if my host goes down, I can move, and my followers are none the wiser.

How will others build applications on top of atproto?

You can create an atproto app by creating a Lexicon. You’ll then want to run an App View that does things with data on the network involving your lexicon, and your application will want to give people the ability to write data to their PDS using your lexicon.

I myself am considering doing so. We’ll see.

Concluding thoughts

So yeah, on the technical side of things, that’s an overview of how atproto and BlueSky work. I think this design is very clever. Furthermore, I think the separation of concerns between atproto and BlueSky are very meaningful, as having a “killer app” for the network gives a reason to use it. It also is a form of dogfooding, making sure that atproto is good enough to be able to build real applications on.

I’m sure I’ll have more to say about all of this in the future.

Here’s my post about this post on BlueSky:

Steve Klabnik @steveklabnik.com

With BlueSky finally opening up federation, I think it's time to write up something that explains the whole thing, BlueSky, atproto, the works, in one easy to find place. Just the high level bits, hopefully something that any developer can understand: steveklabnik.com/writing/how-...

February 24, 2024 at 9:39 PM

665 240

Read 47 replies on Bluesky

A commentor points out https://book.peergos.org/, which I had not heard of, but apparently was known to the creators of BlueSky before they made it. Neat. ↩

Steve Klabnik — ATProto & Bluesky

Too many words about DIDs

DIDs and DID Documents

did:web

did:plc

Does Bluesky own your identity?

In summary

Thoughts on Bluesky Verification

The golden rule of atproto

How verification works

Conclusion

How Does BlueSky Work?

Why does BlueSky exist?

Is this a cryptocurrency?

What is the big picture with atproto?

What is “speech vs reach”?

What are feed generators?

What are labelers?

How does moderation work in atproto?

How does identity and account portability work?

How is BlueSky built on top of atproto?

How will others build applications on top of atproto?

Concluding thoughts

Footnotes

`did:web`

`did:plc`