Hello, hello. Okay. Hey everybody. My name is Daniel Holmgren. Uh I'm the head of protocol at Bluesky. Uh just a heads up. I've been losing my voice all week. I thought maybe if I drank six Modellos at the after party last night, that would loosen it up. And the jury's out on if that's working or not. So I'm hoping that I'm good for the for this talk. To tell you a little bit about so I I lead protocol uh development and design at Bluesky to tell you a little bit about our team. Right now it's technically just me and Brian Newbold on it, although we collaborate closely with other folks from the Atmosphere team.
Without going into our whole org structure, the reason that we split out this protocol department is that protocol design and government governance just looks pretty different from running a startup. You want to make slower intentional decisions and you don't want it to get caught up in sort of the the market and the product life cycle of the startup. So we put up a little bit of a internal firewall for that department so we can go a little bit slower and we can be focused on what we really care about with the protocol, which is the emergence of a functioning, resilient, multi-stakeholder Atmosphere.
So I want to start with the provocation, which is that it's logically impossible for Bluesky to decentralize the network. We really want the network to be decentralized. It is impossible for us to do it because we are the party, right? And even if we funded somebody else to do it, they're still downstream of us, and it's not actually do they actually have the authority, do they actually have the power? In we're the central entity, we can't decentralize it. We can provide the tools and structures by which to decentralize it, but we need others to use those tools and structures to take control, power, and authority in the network to actually make this a resilient multi-stakeholder network.
Uh so that's what I'm gonna be talking about today is those tools and structures and how we address that. The agenda is pretty brief. We're gonna talk about the IETF, uh, some recent developments with PLC governance, and then uh hard decentralization, which is kind of getting into the actual threats of what having a big entity in the middle of the ecosystem could do. Uh before we do that, I'm on the big stage and I wanted to talk about the real governance question, which is how do we capitalize and stylize AT Protocol. Again, this is a multi-stakeholder network, so this is just my opinion.
It just happens to be the correct opinion. You can see AT Protocol, atproto, all lowercase, not a capital A, and Atmosphere. The rest of these are out, especially capital A, capital T, capital P proto. That one is terrible and it needs to be killed. Okay, now on to the real stuff. Uh talking about the IETF or who gets to decide what the protocol actually is. So what is the IETF? It's the Internet Engineering Task Force. Uh it's the standards body for the internet. It standardized all the protocols that you know and love. I'm sure that you're familiar with a lot of these SMTP for email, HTTP for the web, TLS, it gives you the little green lock uh that tells you that your website's secure, web sockets, OAuth, and more.
Uh to tell you a little bit about the vibe of the IETF, it's a pretty weird idiosyncratic organization. I have a quote here from uh Snarf that I think captures it pretty well. He said, standard standards bodies or bureaucracy for good, which I think sums it up. It's uh pretty bureaucratic, it's pretty pedantic, but it's ultimately a very idealistic organization. Uh and it's a very neutral, credible body, and they do a very good job sort of stewarding and owning these sorts of internet protocols. So it's a mix of institutional, but it's also grassroots. You kind of have like a lot of old internet heads there.
You have activists, you have academics and researchers, you also have folks from the big tech companies, Google and Cloudflare and others. Uh and that also gives it this mix of idealism and pragmatism. People have conversations about keeping the internet decentralized, but also they care a lot about the internet working well. Uh and so they have this very pragmatic approach. Uh the kind of motto there is that decisions are made by rough consensus and working code, which I think actually gives a good sense of that idealism and pragmatism. They want to see something working and they want to get a bunch of diverse voices in the room and have general agreement on it.
It's open membership. Anyone can join. You don't need to pay money to join. You can just hop in the mailing list, start participating, you can show up to meetings and start participating. And companies are not members of it, individuals are members. And I put kind of here because most people have an affiliation with a company and it's like they kind of wear it's pretty clear that they are affiliated with companies. Uh but it it is still it kind of gets at their their ethos uh in a way, which is that these are these are engineers coming together trying to reach consensus on protocols.
So the exciting news is we have a working group at the IETF. Woo!
Also, huge kudos to Brian on that. Brian really let up the standards work. In all honesty, he should be the one up here presenting all of this. He's just done an incredible job at that. The working group is called authenticated transfer or ATP. This is the URL for it. The responsible area director is Andy Newton. The working group chairs are Shu Ping and Shu Pingpeng and Mallory Nodell. Brian and I got the chance to chat with all three of these folks uh earlier this week. Generally got very good vibes from them. They're ready to hit the ground running.
They're kind of like start engaging on the mailing list, draft up some stuff. Uh we want to have a lot of energy at the first meeting, so uh the vibes were good. I'm excited about this. This is our charter in very small font. You can read the entire thing on the IETF data tracker. Uh this was on the note of bureaucracy for good. This was four months of going back and forth on a mailing list to get that nailed down to decide what we were going to work on. Uh and to break down kind of what's in that, the what the charter for this working group is for is the structure of the repo and how we encode records in it, the sync protocol for public repositories, the AT URI scheme for addressing records in those repositories, and then interface requirements and selection criteria for an identifier resolution system.
Uh this was kind of the hardest part of nailing down the charter, which is that we did not want to pull DIDs into the IETF. We did not want to wade into the quagmire of specifying identity. Uh so we kind of there's an identity-shaped hole in the spec, and we're specifying the shape of that hole. Uh we are not going to be this working group is not going to be doing lexicon, any microblogging or social semantics at all. Identity, as I mentioned, labeling, and the permission data work that we're working on right now is outside of the working group as well.
Uh, though parts of this may we may recharter the work if everything goes well for both parties, we may be recharter the working group in the future and address some of these. So just to call it out this is your chance to contribute to the technical direction of the protocol. As I said, this is open membership. Anybody can hop in here. If you think that we screwed it up and the protocol is stupid or ugly or whatever, this is your chance to say it and actually have an impact on the protocol. You in in some very real sense, you are on an equal playing field as Brian or I uh on that mailing list and in that room.
Uh so just to give you a sense for participation, as I said, anyone can participate. There's three in-person meetings a year, one in North America, one in Europe, and one in Asia generally. They have a very good remote first experience. Uh and usually if you're attending remote and only for one day, they'll give you a free ticket. Uh so that is that is great. Uh the first working group meeting will be will probably be at IETF 126 in Vienna, which is this summer July. We may do a remote interim meeting beforehand, uh, and I will keep people updated on that.
But regardless, follow along on the mailing list. It's ATP at IETF.org. Brian and I are gonna be trying to send out some stuff on there uh somewhat soon. So hop in and let us know your thoughts. Okay, on to the next one. PLC, or what about that centralized server at the bottom of the stack. Uh for those that don't know, PLC is the identity identifier, not identity, the identifier system for the AT Protocol. Uh it's where your keys are stored, uh or yeah, it describes your public keys and your service endpoints, and it's kind of this centralized server run by Bluesky right now at the bottom of the stack.
My odd take is PLC isn't that bad. The threat model is actually pretty limited. Uh everything is cryptographically signed. Uh the threat model of what whoever is running the PLC directory, what they can get away with is not that much. They can't arbitrarily change your identity or anything like that. They can essentially do denial of service attacks, removing operations from your identity, or refusing to serve your identity. Uh those aren't good, but just to note the threat model is pretty limited. All that being said, it still needs some work. Uh and so we're sort of thinking about maturing governance of PLC as we go along.
We'd like to use DNS and ICANN as an example. Um, mostly for an analogy of iterative maturation of governance. DNS has issues, ICANN has issues, don't overthink the analogy, but you can kind of see how DNS evolved over time. Started as a text file that got distributed to different hosts in the network, moved to a single server that was a computer under the desk, transitioned to multiple root servers. ICANN got set up as a governance body for it, and ICANN continues uh to evolve in their governance, uh being more and more multi-stakeholder, taking into account other countries outside of the US more.
Um, this is sort of the model that we look at with PLC is uh, you know, like we don't have to get it to the end state of like this is the perfect PLC forever or something tomorrow. It's how can we iteratively move that forward as the like kind of threat model for the Atmosphere evolves. So the exciting news to announce is that Public Ledger of Credentials organization has officially been founded as a Swiss association.
Again, huge kudos to Brian for leading this up, as well as Matt, our head of legal, which if you guys can find, I don't know if Matt's here, but if you guys can find Matt, you should chat talk to Matt. He's like protocol pilled now, it's very fun. Uh so we put a lot of thought into who is going to be on the board for uh PLC. Like we we wanted a board that people in the ecosystem could really trust uh to run this thing, and I think that we found the perfect one, which is it's just gonna be Roscoe.
I think Roscoe is just gonna run this. Uh no, I'm kidding about that. This is this is going to be the actual board uh for the PLC Association. There's five members. Uh Brian, who is on the Bluesky team, he's a protocol engineer on the Bluesky team. Uh he's the best person from the PLC or from the Bluesky team uh for this. Richard Barnes, uh, he's the co-founder of Let's Encrypt, which has uh some analogies to PLC. It looks pretty similar to PLC. He's also the co-author of the MLS, Acme, HPKE, all of these deep crypto IETF specifications.
Uh Wendy Seltzer, who's an internet lawyer and open standards advocate. She's here at the conference. You should find her and talk to her if you're interested. Uh Filippo Val Sorda, who's a cryptographer. Uh he maintains the Go Cryptography Library, and he's also a transparency log aficionado and is working on the Project Sunlight implementation. He is also here at the conference. You should come talk to him. Uh and then Tyla, and I don't know how to pronounce her last name, unfortunately, but she's a cryptographer and a security and privacy engineer at Google. Uh she also lives in Switzerland, which is quite nice for uh organizational reasons.
Um yeah, so just to just to note again, this is like the first step in the evolution of PLC. This isn't the end state of it. We're going to continue working on this. Uh we also haven't actually transferred any assets over to PLC. Uh that is something that we will be doing in the coming months and we'll give updates as that happens. The first order of business is getting the domain name over to PLC. Uh alongside these organizational improvements, we also have some technical improvements to PLC. We ship streaming replication and a replica reference implementation that provides full verification of all directory operations.
Uh there's a number of people that are running this in the network already, and the longer term plan is a sophistication of that, which is transparency logs, and you know that we're gonna do that because we have Filippo on the board. Uh great. Now, so those are sort of like the governance updates on like kind of these core parts of the protocol. This next section is about hard decentralization, or that's great and all, but what happens when Bluesky kills API access? Or servers are actually just physical objects that can be destroyed, unplugged, or seized. This is kind of the real politic of running a multi-stakeholder network where you have one big person at the center of it.
What are the particular threats and what can they get away with. So I want to call out that decentralization isn't just one thing, and we need to think through what those threats actually are. I'm numbers are important, but I'm somewhat uninterested in like what percentage of people are on what thing or what it's what are the actual threats that come from Bluesky being outsized in this ecosystem. Let's think through those threats and think through how Bluesky can address them and how the network can address them. So we're gonna do some threat modeling on what Bluesky could do, and then we're gonna talk through some of the solutions.
So the most common thing that people think of is Bluesky shuts down app view API access. People are familiar with this because a lot of social companies in the past have done it. This is actually sort of the threat that I'm least concerned about uh because data access is guaranteed by the open hosting PDS layer. As long as the hosting layer, that's the network inherits its openness from the PDS layer. And as long as the hosting layer remains locked open, then these other app view implementations can emerge as the need arises. I've somewhat jokingly in the past called this lazy decentralization.
That it's if you trust that the hosting layer is open, then you don't need to decentralize the app layer yet. But you have to trust that the hosting layer is open, and we'll talk about that in a second. Still the things that we need for this are tools for backfilling the network and syncing the network and also app view implementation code. So now to talk about if we screwed up the hosting layer, this would be Bluesky shutting down access to the PDS or access to the open data that's hosted by the PDS. Uh to note Bluesky, if Bluesky were to do this, it destroys all of the feeds, apps, and labelers running on the protocol.
So the pain of destroying the network of open applications needs to be severe enough that Bluesky cannot consider shutting down our PDS ac uh PDS access. A smaller version of this attack would be Bluesky may stop serving data to particular competitors. So if one big uh competitor emerges in the ecosystem, maybe we keep sharing data to all of the feeds and labelers out there, but we cut off access to that one larger competitor. The things that we need to prevent this are a thriving network built on open data. If people are relying on open data, then we're incentivized to not cut off access to it.
And then specifically on this cutting off access to particular competitors, all of the data is signed and rebroadcastable. That means that you can get it from any source. You can get it from the Bluesky PDS or you can get it from another PDS. So we need multiple sources to get data from.
What we need to prevent this is a critical mass of users on non-BlueSky PDSs and other applications that do index non-BlueSky PDS data. And that I want to call out that that critical mass.
You can imagine 5% of the network, if we're even less than that. If it's an important 5% of the network, they would be disruptive enough that if you cut off access to them, people would be upset and leave the Bluesky app. This threat also becomes much less substantial if people can just go to another app that is indexing both Bluesky content and content from non-BlueSky PDSs. So having other applications in the network uh helps prevent this threat. Uh another threat is Bluesky messing with accounts. Uh examples of this are preventing users from migrating between PDSs, uh deplatforming users, especially if we don't have just cause, uh preventing users from using certain apps or competitors.
The things that we need this are bas need to prevent this are basically account recovery or export tools. So backups of repositories if Bluesky is refusing to serve your repository to you, user held recovery keys in case Bluesky is refusing to sign uh account migration operations on your behalf, and then just a place to go, uh non-BlueSky PDSs running in the network that you can migrate to. Uh and then the final threat is uh Bluesky just losing access to accounts. Uh this may be uh sort of out of ill intentions or this may be external forces.
So going out of uh business, you know, a data center blowing up, legal action, servers getting seized, something like that. I would expect in most cases Bluesky should be able to help ease this transition. For instance, like the most likely one of these is probably Bluesky going out of business. And we should be able to help ease the transition if that were the case, even if we stop providing PDS services, it's very cheap for us to keep some PDSs online and rotation keys as people move off. In extreme cases where Bluesky is refusing to do that or unable to do it for some reason, we essentially need the what we got from the last threat, which is backups of repositories and user-held recovery keys.
So polling out the things that we found that we needed for each of these, it's basically app view implementation and sync tooling. Uh nice. More users on non-blue sky PDSs, so a more diverse open data hosting layer, uh consumer key management and recovery tools, putting uh rotation keys in the hands of users, other data sources and backups for repositories, and then a thriving ecosystem built on open data. So I want to walk through each one of these and talk about what the Bluesky team can do, what we are doing, and then what folks in the ecosystem can do if you're concerned about these particular threats.
So first on App view implementation and sync. Relays are cheap now with sync 1.1. Fig is running a relay for under $5 a month. That's awesome. There's over 10 full network relays running in the network. We seem to be getting pretty good at doing this one. So you can get your data from a lot of different sources.
Uh is helping with sync. And then BlackSky is actually running a full network app view, which is incredible.
So in some sense, I kinda think this one's this one's solved. Although we can always do better on it. But there's also novel approaches like Red Dwarf that provide a Bluesky like experience with no app view. And so there's ways to rethink what this looks like in the network, where maybe I think it's amazing that Black Sky's running a full network app view. I think that you can probably provide Bluesky like experiences for significantly cheaper if you make certain trade-offs in how you in how you construct this. The next one, Cuba joked that uh we should take a shot every time this uh graph is showed at the conference, and I told him I got one one more for them.
Uh the next one is more users on non-blue sky PDSs. Uh this is a graph of weekly users posting from non-black Bluesky PDSs, and you can see that the trend line is pretty good. So, in some sense, we just gotta keep cooking on this and doing what we're doing. Uh what Bluesky, what we can do and what we're planning to do to help with this is putting an account migration UI in the PDS. Um we think that users, especially non-technical users probably just have a better trust relationship with the Bluesky PDS or yeah, with the Bluesky PDS and would trust an account migration UI there a little bit more to get over to non-uh Bluesky PDS hosting.
We want to improve the PDS distribution, especially for mid-size deployments, things in the 1,000 to 100,000 user range. Right now it works pretty well for self-hosters and small groups of people. It's a little bit of a pain for mid-size deployments. And then we also want to make the relay more uh self-serve, both for third-party relays so that it's easier for them to get proactive write notifications whenever PDS is right, but also for our relay doing dynamic rate limits so that you guys don't have to DM us whenever you run into that and you get cut off from the relay.
Um what what you all can do for this to improve this is keep cooking and also backup and recovery systems. We talked about backup and recovery systems in the context of sort of Bluesky threatening people's repositories and keys, but it's also important for migrating off to non-blue sky PDSs because you you don't necessarily you know you're taking on an operational risk whenever you do that. You kind of know Bluesky has money and we and you know how we operate stuff and you know that we're probably keeping your data secure. Whenever you move to another uh PDS or even self-hosting, you take on some operational risk and having backup and recovery systems can give you peace of mind to do that.
Uh the next thing that we called out was other data sources and backups for repositories. Uh Phil, Fig, bad example, just announced Hubble, which is funded via a grant from Bluesky. I'm super stoked about this project. Hubble's a full network mirror of public repositories. The relay used to offer this. Whenever we switched to sync 1.1, it no longer mirrors all the public repositories in the network. Uh and so this provides a full network copy of all of the data. It's intended to increase network resilience. This is a backup of your repository. If your PDS crashes and burns and you lose your repository, you can go get it from here.
If Bluesky tries to lock you out of it, you can go get a backup of your repository here. Or if Bluesky shuts down our APIs, then you can go sync repositories from Hubble. All of the code will be open source and permissibly licensed. Phil's planning on running an instance of this, but anybody can run an instance of this and provide a full network mirror. Uh consumer key management and recovery tools. I actually think that there's a really great product opportunity here, and I'm kind of surprised that nobody's done it. You can take advantage of phone TPMs for storing recovery keys in a very secure way.
Uh this application could also audit PLC and notify users of any unexpected operations. And I uh just to note, I also think that this would partner well with a backup or recovery service, especially whenever we put out permission data. And then the final thing is just a thriving ecosystem built on open data. And this is I think the biggest part where you all come in. Apps built on the Atmosphere, atmospheric websites, feeds, labelers, social media tools, anything that requires that the data be open. In some sense, all of the previous threats that we talked about are they're pretty protocol-brained, and I just don't think a lot of users are going to care or engage about that.
And I don't think that we're going to get to like an even distribution of users by focusing on key recovery or non-blue sky PDSs or anything like that. The most important thing for the resilience of the network is that users need to understand that they're participating in a multi-stakeholder network, that they're participating in the Atmosphere, that they're not participating in Bluesky. And so if we're building things that run on open data and users fall in love with open social and these experiences that you can only build on open data, that is the most important thing that we can do to keep Bluesky honest and to keep the open social web running.
So the best way to ensure the resilience of the network is to build something that people love so much that they would revolt if it won if it ever went away. Sweet. Thank you.
We're uh that's great. It's awesome. Um we should get that done probably by next week, week after next. So it's great. Yeah. Easy. Uh we're heading into the coffee break and we have a couple of minutes. Uh questions. So users knowing that they're participating in the Atmosphere, not just Bluesky. How do we do it? What's the branding? That's a great question, and we should figure that out. This gentleman just showed you an ASCII presentation. This presentation came from our designer. I want to call that a uh no, that's a that's a good question. I think that that is I mean, I don't have the answer for you right now, but that is the core question that we need to figure out this year is how do we start to build intuition for users about what the Atmosphere is, what they're participating in, what an Atmosphere account is, and what this whole open social thing is about.
How is the uh Spus Association funded? Is that like a grant from Bluesky? And how does this thing continue even if one of your scenarios blue skies went went away? That's a good question. Uh right now it is funded via a grant from Bluesky. Uh the exact details of that haven't been nailed down just yet, although it will probably provide some sort of ongoing funding, and then the association is going to be working to provide you know more sustainable funding options after that. But ultimately that's going to be the prerogative of the Swiss Association, not Bluesky.
Let's go get some coffee. Thanks, Dan.