Hello? Hello?
Okay. Hey, everybody. My name is Daniel Holmgren. I'm the head of protocol at Blue Sky. Just a heads up, I've been losing my voice all week. I thought maybe if drank six Modelos 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 development and design at Blue Sky. tell a 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 wanna 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 care the protocol, which is the emergence of a functioning resilient multi stakeholder atmosphere.
So, I want to start with the provocation, is that it's logically impossible for Blue Sky 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? And 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.
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, some recent developments with PLC governance, and then, hard decentralization, which is kind of getting into the actual threats of what having a big entity in the of ecosystem could do. 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, at proto, all lower case, 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. 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. 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 that tells you that your website's secure, WebSockets, OAuth, and more. 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, 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, pretty bureaucratic. It's pretty pedantic, But it's ultimately a very idealistic organization and it's a very neutral credible body, then they do a very good job sort of stewarding and owning these sorts of internet protocols.
So, a mix of institutional, but it's also grass roots. 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. And that also gives it this mix of idealism and pragmatism. People conversations about keeping the internet decentralized, but also they care a lot about the internet working well. And so, have this very pragmatic approach. 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 wanna see wanna get of room and have agreement it. It's open membership. Anybody 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 the company and it's like they kinda wear it. It's pretty clear that they are affiliated with companies, but it it is still it kinda gets at their their ethos, 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. Also, kudos to Brian on that. Brian really led up the standards work. 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 Ping Peng and Mallory Nodel. Brian and I got the chance to chat with all three of these folks earlier this week. Generally, got very good vibes from them.
They're ready to hit the ground running. They're kinda like start engaging on the mailing list, draft up some stuff. We wanna have a lot of energy at the first meeting. So, 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. 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. 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. 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. So, we kind of There's a identity shaped hole in the spec, and we're specifying the shape of that hole. We are not going to be This working group is not going to be doing lexicon, any micro blogging, 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. Though, parts of this may, we may have recharted the work. If everything goes well for both parties, we may be recharted 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 on that mailing list and in that room. 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. And usually, if you're attending remote and only for one day, they'll give you a free ticket. So that is that is great. The first working group meeting will be will probably be at IETF one twenty six in Vienna, is this summer, July.
We may do a remote interim meeting beforehand, and I will keep people updated on that. But regardless, follow along on the mailing list. It's atp@ietf.org. Brian and I are gonna be trying to send out some stuff on there 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? For those that don't know, PLC is the identifier, not identity, the identifier system for the AT protocol. It's where your keys are stored or yeah. It describes your public keys service endpoints, and it's kind centralized server by Sky at bottom of the
My outtake is PLC isn't that bad. threat model actually pretty Everything is cryptographically signed. 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. Those aren't good, but just to note the threat model is pretty limited. All that being said, it still needs some work. 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. 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. It 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 to evolve in their governance, being more and more multi stakeholder, taking into account other countries outside of The US more.
And so, this is sort of the model that we look at with PLC is, 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 try talk to Matt. He's like protocol pilled now. It's very fun. So we put a lot of thought into who is going to be on the board for PLC. Like, we we wanted a board that people in the ecosystem could really trust to run this thing. And I think that we found the perfect one, which is it's just gonna be Roscoe.
I think I think Roscoe is just gonna run this. No. I'm kidding about that. This is this is going to be the actual board for the PLC Association. There's five members. Brian, who is on the Blue Sky team. He's a protocol engineer on the Blue Sky team. He's the best person from the PLC or from the Blue Sky team for this. Richard Barnes, he's the co founder of Let's Encrypt, which has some analogies to PLC. It looks pretty similar to PLC. He's also the co author of the MLS, ACME, HPKE, all these deep crypto IETF specifications.
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. Filippo Valsorta, who's a cryptographer. 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. 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. She also lives in Switzerland, is quite nice for organizational reasons.
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. We also haven't actually transferred any assets over to PLC. That is something that we'll 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. Alongside these organizational improvements, we also have some technical improvements to PLC. We shipped streaming replication and a replica reference implementation that provides full verification of all directory operations.
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 Filipo on the board. 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 blue sky 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 wanna call out that decentralization isn't just one thing and we need to think through what those threats actually actually are. 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 Blue Sky being outsized in this ecosystem. Let's think through those threats and think through how Blue Sky can address them and how the network can address them. So, we're gonna do some threat modeling on what Blue Sky could do and then we're gonna talk through some of the solutions.
So, the most common thing that people think of is Blue Sky 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 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 Blue Sky shutting down access to the PDS or access to the open data that's hosted by the PDS. To note, Blue Sky if Blue Sky 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 Blue Sky cannot consider shutting down our PDS PDS access. A smaller version of this attack would be Blue Sky based stop serving data to particular competitors. So, if one big 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 Blue Sky PDS or you can get it from another PDS. So, we need multiple sources to get data from. The next sort of threat is Blue Sky stops crawling non Blue Sky PDSs. So, these are folks that have migrated their account off of the Blue Sky PDS and the Blue Sky app view stops indexing non Blue Sky PDS data. Their motivation to do that would be to monopolize hosting.
What we need to prevent this is a critical mass of users on non Blue Sky PDSs and other applications applications that that do do index index non non Blue Blue Sky Sky PDS PDS data. Data. And that I wanna call out that that critical mass basically, we need the critical mass because if Blue Sky were to stop indexing this, you needed to screw up people's experience of the app. They would get pissed because there's data that they wanna see that they're not seeing in the Blue Sky app. I wanna call out that I don't think that we need like an even distribution of users across hosting infrastructure in the network in order to achieve this.
You can imagine 5% of the network if 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 Blue Sky app. This threat also becomes much less substantial if people can just go to another app that is indexing both Blue Sky content content from having network threat. Another Blue Sky messing with are from between de platforming if we have Just Cause, users from using apps or competitors.
that need bay need to prevent this are basically account recovery or export tools. So, backups of repositories if Blue Sky is refusing to serve your repository to you, user held recovery keys in case Blue Sky is refusing to sign account migration operations on your behalf, and then just a place to go. Non Blue Sky PDS is running in the network that you can migrate to. And then the final threat is Blue Sky just losing access to accounts. This may be sort of out of ill intentions or this may be external forces.
So going out of business, you know, a data center blowing up, legal action, servers getting seized, something like that. I would expect in most cases, Sky should be able to help ease this transition. For instance, like the most likely one of these is probably Blue Sky 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 PDS's online and rotation keys as people move off. In extreme cases where Blue Sky 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, pulling out the things that we found that we needed for each of these, it's basically app view implementation and sync tooling. Nice. More users on non blue sky PDSs, so a more diverse open data hosting layer. Consumer key management and recovery tools putting 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 wanna walk through each one of these and talk about what the Blue Sky 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. There's lots of new sync tools coming out. We published TAP, hydrant, the entire FigProto Microcosm universe, 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 blue sky 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 Blast Sky is running a full network app view. I think that you can probably provide Blue Sky 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 we should take a shot every time this graph is showed at the conference, and I told him I got one one more for him.
The next one is more users on non blue sky PDSs. This is a graph of weekly users posting from non Blue Sky 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. What Blue Sky what we can do and what we're planning to do to help with this is putting an account migration UI in the PDS. We think that users, especially non technical users, probably just have a better trust relationship with the Blue Sky PDS or yeah. With the Blue Sky PDS and would trust an account migration UI there a little bit more to get over to non Blue Sky PDS hosting.
We wanna improve the PDS distribution especially for mid sized deployments, things in the 1,000 to a 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 sized deployments. We also wanna make the relay more self serve both for third party relays, so that it's easier for them to get proactive right 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.
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 Blue Sky 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 you know, you're taking on an operational risk whenever you do that. You kind of know Blue Sky 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 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.
The next thing that we called out was other data sources and backups for repositories. Phil, Fig, bad example, just announced Hubble, which is funded via a grant from Blue Sky. 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. 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 Blue Sky tries to lock you out of it, you can go get a backup of your repository here. Or if Blue Sky 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. 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 restoring recovery keys in a very secure way.
This application could also audit PLC and notify users of any unexpected operations and I 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 blue sky. And so, if we're building things that run on open data and users fall in love with OpenSocial and these experiences that you can only build on open data, that is the most important thing that we can do to keep Blue Sky honest and to keep the OpenSocial 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 went if it ever went away. Sweet. Thank you.
speaker-1 We're that's great. It's awesome. We should get that done probably by next week, week after next. So it's great. Yep.
speaker-0 Easy.
speaker-1 We're heading into the coffee break, we have a couple of minutes. Questions?
speaker-2 So users knowing that they're participating in the atmosphere, not just blue sky. How do we do it? What's the branding?
speaker-0 That's a great question, and we should figure that out.
speaker-1 This gentleman just showed you an ASCII presentation.
speaker-0 This presentation came from our designer. I wanna call that a 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 OpenSocial thing is about.
speaker-3 How is the Swiss Association funded? Is that like a grant from Blue Sky? And how does this thing continue even if one of your scenarios Blue Sky went went away?
speaker-0 That's a good question. Right now, it is funded via a grant from Blue Sky. 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 Blue Sky.
speaker-1 Let's go get some coffee. Thanks, Dan. Nice.