BlueSky's Not the Limit: Hacking Stuff With AtProto

Thanks Hernando. So I'm going to be talking about BlueSky and AtProto. I should be clear I'm not going to be speaking for BlueSky. I don't work for BlueSky. I didn't help design AtProto.

I do Reality.E which is a smart contract Oracle. I'm going to talk about AtProto because I like it. But what I've done is if you go to my profile GoatNavy on BlueSky I've pinned a link to a whole load of stuff including some stuff by the original people who actually did build AtProto and a whole bunch of other resources. So long ago the internet kind of looked like this.

If I wanted to publish something and share it with my friends I would make my HTML page and upload it to my web server and then you could use your browser to download it from the web server. This of course is not a peer-to-peer arrangement. It's a client server arrangement. But it has some really nice properties that we are often looking for when we do peer-to-peer stuff. So anybody can publish.

Nobody can stop you publishing. You can self-host if you want to. I think at one point I did. But normally you use shared hosting and the great thing about when you're using shared hosting is it doesn't really matter what the hosting does. The hosting is unopinionated.

The hosting doesn't have editorial control over what you're putting on that web server. And if the hosting does screw you then you just move your DNS over somewhere else, restore from backups and then carry on. So the user doesn't really notice. But then we went a different way on the internet. We did web 2.

0. And this brought us a load of stuff that was missing in the original web 1. That we wanted social connections. We wanted the social graph so I could see what my friends were following. I wanted to see all my friends in one view.

We needed identity built in. We needed data structure. So on a tweet you've got tweets and retweets and likes and all this stuff. And we also needed kind of resilience. So often in the early web, if your thing went viral and you got a lot of traffic, the web server would fall over.

We solved that in web 2.0 by everybody using the same three websites. So we have an internet that looks more like this. All your stuff goes in a database on some guy's web server. One of those guys was Jack Dorsey, web 2.

0 entrepreneur. And sometime in about 2018 he went to Myanmar and he made his case in a cave and he came back and he read a thing by Mike Maznik called Protocols Not Platforms. And he said, you know what, I shouldn't have editorial control over your entire life. Twitter should have been a decentralised protocol rather than a centralised server. So he got together a team of people that was supposed to decentralise Twitter.

And that brought us what was originally the Blue Sky Project and App Proto. So the constraint that these people had in building App Proto was it was supposed to be able to run Twitter. So that means it's got to scale to the size of Twitter and you also have to have a user experience like Twitter. You can't say this is decentralised so you're just going to have to suck it up if the notifications don't arrive or something. It has to work like a normal web 2.

0 product from the point of view of the user. So they designed that proto. Then while they were doing that Elon Musk took over Twitter and they ended up running a completely separate kind of rival Twitter clone built on their protocol. But the idea was always that Blue Sky would be the first application on this platform. The slogan was the company is the future adversary.

So you remember Google had like don't be evil, which was sweet. The thinking here is that if you use Blue Sky now and you're relying on some Blue Sky infrastructure, sooner or later Blue Sky is going to screw you, right? So sooner or later we need you to be able to move off Blue Sky and when you move off it, ideally not only can you preserve your social graph and all that stuff, but ideally you'd actually preserve the entire experience. So you shouldn't really even have to notice that you're no longer on Blue Sky infrastructure. So they released Blue Sky.

A bunch of people showed up. Jack Dorsey had a really bad time on Blue Sky and he threw a massive huff and flounced and left the board. So he's no longer in any way connected. It's just this entirely separate organisation that is standardising at proto and is supposed to be maybe handing that off to another standards organisation. So how does it work?

Well the core thing at the centre of it is what's called the PDS. So this is my web one slide and I've just rubbed out web server and I've written in PDS. So how is a PDS different? Well it's a structured data, so everything that goes in there follows some lexicon that you've defined that decides how the data all relate to each other. It's attached to an identity, which I'll get to in a second.

Your records in it are also connected to other people's identities. So you've got your whole social graph is preserved inside these records and it's content addressed and cryptographically signed. So this means that you don't necessarily have to get your data from the place that originally published it. So if I'm hosting my own PDS, I can do that on a really, really tiny little rubbish VPS and that doesn't matter because if my content goes viral, people aren't going to be getting it from my PDS, they're going to be getting it from some cache or some other party. And because it's content addressed and cryptographically signed, they can verify that it's what it should be.

Okay, there's a little bit more infrastructure. So if you just had users with their clients and they were connecting directly to the PDSs, that would actually work, but it wouldn't be that performance and it wouldn't be that convenient. So there's a load of infrastructure in between. I'll kind of skim over it. There's a piece in my links at the end by Paul Frazee talking about turning the data centre inside out, which I'd really recommend.

But what you've got here is you've got the relay. The job of the relay is to connect to all these PDSs and catch all of the latest changes and then just kind of splurge them out in what's called the firehose. So you have this kind of constant stream of all of the new changes happening on the entire network or a subset of the network. Then you've got your app views. These are kind of back-end servers that the clients are going to use.

So these will depend on kind of exactly what the client wants and what the client is for. So when we started off, this was all stuff that Blue Sky Company was running. Now we've got quite a lot of independent infrastructure. Other people are standing up relays and app views. So all of the data in the PDS lives in a Merkle tree.

It's a slightly exotic kind of Merkle tree called a Merkle search tree. Again, in the links there will be some stuff about why a Merkle search tree was chosen and what is interesting about it. But what we're going to do is if we make a post, we're going to take its hash, make a CID. This is a content ID that looks just like IPFS IDs. That's going to go in some node in that tree and that will allow us then to always make a proof that that is somewhere in the tree and it will update the root hash.

And then we're going to assign that root hash and that will allow us to verify the data. For identity, there are two standards in AppProto. There's one called DidWeb. This is an old W3C standard. Basically you put an identity document on a web server.

The other is DidPLC. The idea of PLC is we want to get as close as we can to content address data. Ideally, you could get all the data in that identity document and you could look at the ID and verify that the data was correct. That absolutely works for the absolute first update and it kind of works for subsequent updates with a few slightly cursed edge cases. Let's talk about making some stuff.

The first thing is what can we do on BlueSky? All of the curation and the moderation and all of that stuff is unbundled in BlueSky. If you're using Twitter, you have, for example, the For You feed and that is what Elon Musk and his algorithm decided you should have in your feed. In BlueSky, there is also a built-in feed. It's called Discover and it's really rubbish, but luckily you can make your own.

This is my BlueSky when I'm logged in. I've got a bunch of different feeds I've added. I've taken out the Discover one because it's awful. I spend a lot of time on Likes of Likes. This is something that some guy in Japan made.

It's just like things that people whose stuff I like at one remove, which turns out to be actually a really good algorithm, just really simple. I've got Quiet Posters. This is people who I follow who don't post very much and I want to see what they do post. Of course, you can also do thematic stuff. If you want to see stuff about goats, you can make a feed of goats.

This is really easy to build. You make a program that's just going to ingest the fire hose, this information from the relays of just all of the new stuff getting posted to the network. You decide what you like and you output this ID to that user. That's all you have to do and then the user can really easily add it to their clients and automatically subscribe to what you're posting. Similar story for Block Lists.

On Twitter, Elon Musk decides who shouldn't be seen. On Blue Sky, you can make your own decisions about who you don't want to see. You can put people in lists. Anyone can make a list. You can make lists of people you want to follow because their stuff is good or you want your friends to follow and people you want to be blocked.

I'm on a list of goat posters because I post incredible goat content. I'm on a technology list for people who like technology. I'm on a tech shit list for people who don't like technology and just hate Web 3 and crypto and this entire thing, which is, I don't know, it may be wise. Okay, so let's talk about Blockchain Bots. I make a thing called Reality.

if. This is a question and answer system, basically an optimistic oracle. People put questions in it. They then have people post answers and when they post answers, they put up bonds and so there's an incentivized system to get the right answers. So the first thing we did with this is to make a bot to just post all of the questions that we see on the Blockchain onto Blue Sky, very simple.

Once we've done that, it's really easy to put comments into our dApp front end because we know the ID that we posted with. We did that in a deterministic way, so it only needs a tiny little bit of JavaScript to just pull all of the replies to that question in and show them in our dApp inline. But we can also go the other way. We can take actions from AppProto and we can send them to the chain. So I wanted to do some stuff about misinformation for a long time with Reality.

if. So this is just on testnet so far, but we've got like a bot that you can tag the bot, put in a question and it will send the question to the Blockchain and create it in Reality.if so that anybody can answer it. When we do this, we're creating a NoSysFace on-chain so that that becomes kind of the user's avatar, like attached to their key on Blue Sky. We can also answer a question, so if I see a question I know the answer to, I can tag the answer bot and I can put my answer and then put my bond and that will create the on-chain transaction that will make that happen.

Now I've seen stuff like this on Twitter before, other NetChains I've seen it done, but the thing about this is this is entirely trustless, right? Because the content is all on the user PDS, it's arranged in a Merkle search tree and the Merkle search tree route is signed. So we can take some content, we can recover the CID, we can find the CID in the pre-maker proof that it craters up to the route hash and then we can check who signed that commit node. So a nice side effect of this is that since we're creating these automatic NoSysFace, we kind of inadvertently create a crypto account for 36 million Blue Sky users, whether they like it or not. Okay, let's talk about some new stuff, because everything I've talked about so far has been about Blue Sky, but AppProto is a lot more than Blue Sky.

So think about this, the basic thought behind everyone having this PDS is this, everybody in the world gets a self-sovereign, cryptographically verifiable semantic data store. Everyone gets a self-sovereign, cryptographically verifiable semantic data store. This is the correct way to do the internet, right? This is what we should have done when we went to Web 2.0.

So just looking at some stuff, and it's really easy to write to this store, so if you've got a decentralised app, you can do this, you don't necessarily need a server, you can do it with just a static front-end app. You can authenticate against the use of PDS via OAuth, and that will give you the right to write to their PDS and to save records on their behalf. There's also something in the OAuth flow where you can put in a host of PDSs, so right now Blue Sky basically hosts most of the PDSs, but a few different people are now hosting them, so you can put in the PDS host and then that will automatically onboard them onto AppProto and then bring you back and allow you to write to their data store. So a couple of examples of this. One is Tangles.

This is a decentralised GitHub replacement. Another one is SmokeSignal. This is an events management system. In the links there's a really nice thing by Liggy, some of you probably know, who's written about why the existing hosted events management systems are not doing it for us. Another thing that dropped after I made these slides is that the Linux Foundation just did a thing called the Fair Package Manager, which is a package manager for WordPress.

So WordPress recently had some sort of politics where the company that built WordPress has been kind of exploiting its control of the package manager used for plugins, so the Linux Foundation have built their own. So now we have two choices for kind of different purposes when we're building decentralised applications. Some applications will need like a consensus history. Some applications need a piece of data that everybody shares and after you've written it you can't necessarily delete it. And because that's the commons, because it's got to have a consensus, that gives us a whole bunch of constraints, right?

So we have gas costs we've got to deal with, we have potentially slow finality, we have just all this pain that we deal with as blockchain developers. But a lot of the stuff that Web 2.0 did was not like that. A lot of stuff in Web 2.0 is things where the user should have control over their own data.

And the problem that we're trying to solve is we need to be able to easily aggregate all that data and show it in different ways to different people. So that's where I think AppProto fits in. When you've got user controlled data, the user can do what they like with it, the user owns the data, you can put it on their PDS and that will alleviate all this pain that we had to deal with if we had to do everything with a blockchain. And I don't want to do this whole hype thing but I feel like the use cases of consensus history are probably less numerous than the use cases of user controlled history. So many things in Web 2.

0 are user controlled history and not consensus history. So I'm kind of really excited about having this new tool to do this stuff. So like I said, I've put up a bunch of links. There's stuff by the people who actually built the protocol, Jay Graber, Paul Frazee. There's a starter pack if you're not on Blue Sky and you want to get started, there's some people to follow that I can suggest.

And then a whole load of technical details, stuff to help you get started writing bots, all that stuff. Okay, so I feel like this has really kind of restored my optimism about the internet. I don't know if anyone else has done that but I'm really excited about this. I really hope people will give it a try. Okay?

Thank you so much. Let's open it up for questions. One question. Two questions. So I'm interested in building a Blue Sky client for Google and, you know, do we access portal servers and private entities and do they access services in a new way?

How important is that to the client? So I guess the easiest thing would be that you can take any of the existing open source clients. So really just depending how much of a, like how different that is to the thing that you then fork, it will vary. Like, you know, you could imagine you pretty much take an existing client, decide which records you want and then it works. If you want to change a lot of stuff obviously there's more work.

But one of the great things about this ecosystem is that it really is a free software hackers ecosystem. And this is the difference to some of the other projects kind of in the crypto space is that everybody is committed to free software. So you can take the original Blue Sky client or one of a bunch of other clients and work with that quite easily. Thank you very much. For the personal data storage, data storing is also provisioning data to others, making it accessible as a general concept.

And there's also then bandwidth stuff like this. Do you have something like a payments layer for it for a hoster then? Or is this a concept that would be like the next step? There's no payments layer. I don't know how people will feel about like paying for PDS data right now.

If you're doing just Blue Sky data, then you generally are not talking about vast amounts of data. I wouldn't be surprised if Blue Sky do some kind of premium thing with I don't know what features that will have. I hope other people will also do kind of paid services. As far as an actual layer goes, there are a couple of people now doing crypto integration. My friend Stella just did a really nice proposal where she's linking Ethereum addresses and putting in a whole lot of kind of payment stuff.

So we certainly could put in kind of crypto-based payments. I suspect it's more likely to look more like kind of traditional models of like somebody stuffed in some ads or people keep selling other stuff. I don't think there's much demand for kind of micro payment type stuff. And one of the nice things about Blue Sky is that you don't really have to do that if you're just hosting a little bit of data. Again, this is the problem.

If you're trying to do a data commons with a blockchain, then you have the problem of okay, how do we prevent that being abused? So you need gas payments, you need storage rents and all this stuff. But if it's just a little bit of data on a server, there's a lot of ways to get the little bit of money that you need to serve that. Cool.