Bluesky’s Not the Limit: ATProto, How It Works and Why It Matters

EDCON 2025 · 18 Sept 2025 · 16:23

Edmund Edgar follows ATProto from an effort to decentralize Twitter to the protocol behind Bluesky and other applications. He explains how the protocol works and how developers can use it to build new decentralized social experiences, looking beyond the boundaries of a single social network.

Speakers

Topics

From EDCON 2025, hosted by EDCON.

Transcript

Next, we'd like to invite our next speaker, Mr. Edund Edgar. Mr. Edund Edgar, the floor is yours. Okay, I'm going to be talking about App Proto and Blue Sky today. I should be clear, I'm not going to be speaking on behalf of Blue Sky. I don't work for Blue Sky. I run a smart contract oracle called Reality. Um, I want to talk about App Proto because I think it's a really important piece of decentralized tooling that that's kind of just dropped and and it's really not well known in crypto

circles for reasons that I think are kind of more sort of factional and social than uh than technical. So, long long ago, the internet looked like this. If I wanted to publish some stuff and share it with my friends, I would make my HTML page, upload it to my web server, and then they would access my web server and get my stuff. Um, that was not a peer-to-peer system, right? This is a client server system, but it has a lot of properties that we're looking for when we're building peer-to-peer systems. So, anybody can publish. Nobody can stop you publishing.

If you want to, you can self-host. Like at some point, I think I self-hosted my own uh Apache web server. Um but generally, you don't need to because the hosting where you're hosting your static website does not have any editorial control, right? They could, if they wanted to, start fing around with it, but then you can just move your DNS over to a different uh host and then uh just carry on, restore from backups, and then everybody will be able to carry on as normal. Um, so that had some really nice properties, but then we went in a different direction. We ended up with web 2.0. Um, and we did this for some good reasons. There were some missing features that we didn't have in that early web. Um, so we wanted everything

to have a social connection, right? I wanted to see what my what my friends are are posting, what my friends are sharing. Um, we needed identity built in. So, this tweet is funny because I know that the the person posting it used to be the spokesman for the the Irish Republican Army. Um, we needed structured data. So, we need to know like this is a tweet, this is a a retweet, this is a reply. Um, and we need resilience because early on if you had a static website, often if it got very popular, your web server would fall over when everybody hit it at the same time. And we solved this in web. 2.0 0 by having like three web servers in the entire world and everybody accessing those those few servers. Um so it ended up looking more like this. All of your

stuff is in some guy's database that guy now has editorial control over your life. So the the lesson I want to take from this is if you have a decentralized protocol and it's missing some features, the market will supply those features, right? the market will give your users what they need and if it needs to it we'll do it with centralization and this is something that I'm going to come back to. So one of the people who had control over our our social lives who had complete editorial control over everything is this web 2.0 entrepreneur Jack Dorsey.

Um sometime a few years back he went to Myanmar and he meditated in a cave and he was bitten 147 times by mosquitoes and he was enlightened and then he came back and he read Protocols not platforms by Mike Maznik and he said you know what I should not be in control of all of your stuff. It should not all be in a database that I control. Um I should not have editorial control over your life. So he got a team together to build a tech a a way to decentralize Twitter. Um and he hired Jay Greybar who at one time was at uh at Zcash. Um a bunch of other people joined the team from like IPFS and secure scuttlebar and these

other kind of P2P projects. Um and they designed a protocol called ATP proto or at protocol. Um, just as they were doing this, um, Elon Musk bought Twitter. Um, all of the people they were talking to at Twitter got fired or quit. So that the whole project seemed to kind of evaporate. So they said, "Okay, never mind decentralizing Twitter. We've built this protocol. So let's just stand up our own uh social network." But the idea was that this is a a protocol that we can use in all kinds of other ways, not just Twitter. I'm going to come back later to the the other things that people can do. So, they started up a company. The motto of the company is the company is the future adversary. So, remember Google had don't be evil, which

is really sweet. Um, but I think we all know that sooner or later if a company has control over your stuff, they're going to screw you. So, they launched Blue Sky. Um, a bunch of early uh adopters showed up on Blue Sky. Jack Dorsey had a really bad time on Blue Sky, so he ended up storming off in a massive huff. Um, so now Jack Dorsey is no longer on the board of Blue Sky. There's no Twitter connection to Blue Sky. It's a fully independent organization. Um, and they're trying to standardize that proto. So how does the protocol work? Well, at the core of it is what's called a personal data server, a PDS. Um, and what I've done on this slide is I've just taken my web one slide of me hosting my static content.

I've rubbed out the the web server and I've written in PDS. So, how is the PDS different to the web server? For one thing, it's for structured data. Um, so what's a reply, what's a like, um, all that kind of stuff is is stuff that's stored in the uh in your PDS. It's attached to an identity. It can reference stuff with other people's identities. Um, and importantly, everything in your uh on your PDS server is content addressed and cryptographically signed. Um, so this is something that we usually do in pure to peer-to-peer systems so that you can get your data from an untrusted peer. But here we're not necessarily going to get

our data from an untrusted peer. We could do we could also get it from a semi-rusted server, but the point is it doesn't matter where we get it from because we can always verify that our data is correct. Um, and that really helps you solve the scaling problem because I can run my personal data server on my own DAP node or on a really crappy little VPS and even if I get loads of traffic, it's not going to fall over because most people are not actually getting their data direct from my PDS, they're getting it from somewhere else. Um, so if we just did that, we had the data on a personal data server, everybody could then go from their uh client to the PDS and that would work.

You could fill your feed like that. Um, but it's not very efficient. So, there's some more infrastructure. Um, I'm really going to skim over the infrastructure here. There's a really good piece I'll link to the end to at the end um by Paul Frasy called turning the data center in inside out that will tell you a lot more. But fundamentally, you've got a relay. Um, a relay has the job of just crawling all the these different personal data servers, fetching all the latest updates and um and pulling them in and splurging them out so that anybody can consume them. Um, then you've got your app views. These are basically um application backends that uh that can run any application. Um, so let's look at what happens if I make a

post in blue sky. So this is my post. I've typed it in. Um, it's going to be assigned a key. This is a a T ID, a time stamp ID, basically a time stamp with uh with benefits. Um, it's encoded in DAG Seabore, which you'll recognize if you know IPFS. Um, that's put in my text. It's put in the references I have to other people's posts. Um, and a bit of other stuff. And then that's uh that's going to be hashed to make a content ID. Um, I'm going to add that to my um my personal data server. So, this looks a little bit like a GitHub rep a Git repo.

Um it's a Merkel tree, a slightly exotic kind kind of Merkel tree called a Merkel search tree. Um and that's going to be added to that and then we're going to make a commit node which we're going to assign with our key and that will prove that anybody can get my content and check that it is really my content. Um in identity there are two standards. There's one called did web. Um this is an old W33C standard. Um and there's PLC. I will kind of skim over did PLC because I'm short on time. Um but did PLC is kind of kind of trying to get as close as you can to content address storage for identity. Um which it almost but doesn't quite manage.

Okay, I'll say a little bit more about Blue Sky because a a social network is not just posts, right? You've got other aspects to it that are really important. You need to be able to do curation of content. You need to be able to do moderation. And as I said earlier, if you don't build this stuff in a decentralized way, the market will do it, but they will do it in a centralized way. So you'll end up, for example, if you don't have a good way to do moderation, you will end up with the client having moderation features and other people are unable to make competitive clients. So all of this is stuff is unbundled. And I'll show you what you what I mean. So this is my blue sky feed. Um the if I was looking at Twitter there would be like the for you

feed which is an algorithmic feed. Um blue sky has one built in called the discover feed. Um, I've taken that out of my feed and I've replaced it with likes of likes, which is somebody else's contributed algorithmic feed running on somebody else's server and I can very easily add that to my client and automatically pull all of those um pull all of the posts that their feed says that I should have. Um, I've also got quiet posters. This is something that some uh some other guy made. Um, quiet posters is people I follow who don't post very much. Um so all of this is something that um that's decentralized so that anybody can create a feed and then anybody can can subscribe to your

feed. So you're not dependent on um the people who created the application or somebody managing the application um who who is uh managing that for you. Um for moder for moderation um there are some people I don't want to follow. You can put people in lists. So I'm on a goat posters list. This is a list of people people want to follow. Um, I'm on a technology list for people who want to uh to know about technology. And I'm I'm on a tech list for people who don't want to know about technology, don't want to hear about web 3 and just want all that stuff out of their feed.

Okay, so everything I've said right now has been about blue sky, but at proto is a lot more than blue sky. And this is the core thing that at Proto brings us. Everybody in the world gets a self-s sovereign cryptographically verifiable semantic data store. Everybody gets a self-s sovereign cryptographically verifiable semantic data store. This is the correct way to do the internet. This is what we should have done when we went from web one which had some quite good properties to web two which was really horrible and censorship resistant and and censorship easy to censor. Okay, so everybody's got this data store. Um, it doesn't matter where they're hosted.

It's really easy to move it around. Um, if you're building a decentralized application, you can write to their data store. So, you can authenticate with oorthth. Um, that will send them off to their PDS. Um, they can log in and then they come back to your application and you can write data to their personal data store. There's also a nice thing in the oorthth flow where if somebody isn't already a registered user on approto then you can um cause them to be given a place to sign up so they can create their own uh their own PDS. Um all of the data that you put in app proto is going to have some kind of structure to it and you can define the structure of your data. So for example

in blue sky this is the description of a like. So a like looks something like this defined semantically. um says these are the the fields that it has to have. Um this is what the data has to look like. Um and whatever your application is, you can define your own lexicon um and then post the data in in a structure form that you that you need. So looking at some things that people have built. Um this is tangled. So Linus Tovold built Git. Git is a wonderful decentralized system. There's no need to have a a server anywhere if you're using git. I can pull straight from your git repo, straight from my computer. We don't need a server. We don't need a trusted party. But it didn't solve all of the users's problems, right? The user

also needed issue tracking and like PRs and all this stuff. So we ended up everybody using a centralized server called GitHub run by Microsoft. So if we're doing it right, we don't do it like that. This should be decentralized. So, Tangled is an atrotobased um alternative to GitHub. Um there's a very nice events system called smoke signal. Um I'll link at the end to a piece by our friend Ligy who some of you know um who talks about uh using that as an events manager. Um the the line the Linux foundation built the fair package manager for WordPress. So the the WordPress um maintainers have been kind of uh abusing their privilege of running

a a plug-in repository uh and they've been messing around with that. Um so fair package manager is an at protobased system that um that that allows you to avoid that. So this is all stuff that um all all kinds of things are springing up. It's really active right now. Loads of people are building cool stuff with at Proto. Um so if you come to it as a blockchain developer um just kind of uh think about how we can use this. So if you're using a blockchain what that gives you is consensus history right sometimes you need one set of facts the data that you write to it is eternal and nobody is in control of that data but a lot of web

2.0 0 use cases were not actually like that. In web 2.0, what you usually want is user controlled history. The user owns their own data and the user writes their data to their data store. Um, and that's usually what you want, I think, in kind of social context if you're doing social applications. So if you're using a blockchain because we've got this commons, we've got this thing that everybody has to be able to maintain and everyone has to be able to verify, you then need to be able to do like anti-PAM, you need to charge gas to stop people spamming the thing. Um, but if you use each user's PDS and the user is

responsible for their own data, then you don't have to worry about any of those problems. So it's much much easier to onboard people to a decentralized application if you're doing user controlled history with at proto um compared to if you've got to do it with a blockchain. And then if you also have some use cases later on where you also need consensus history then you can bring in the the blockchain part at that point. Okay. So I I hope that makes sense. Um I'm really really excited about proto. Um, it's made me kind of optimistic about the decentralized web in a way that I haven't been uh for a long time. I think I haven't been kind of this excited about decentralized technology since kind of Ethereum actually shipped and and I realized

Ethereum was really going to happen. Um, I've put a bunch of links here. There are some talks by the people who actually built the protocol. Um, there are links to all these different applications on Approto. Um, there's some blockchain integration stuff that that I've built, all kinds of other stuff. So, please take a look at that. And yeah, please have a go with that 80 proto and and see what you can build. >> Okay, thank you very much.