WEBVTT 00:00.000 --> 00:12.720 Without me further ado, I guess. I'll get started. I'm now in Skarnet. I am Devreau at 00:12.720 --> 00:17.880 Blue Sky Social, and I'm here to talk about the app protocol. Thanks everyone for keeping 00:17.880 --> 00:23.640 the energy high until 430 in the afternoon almost. If you go to Blue Sky Social, this 00:23.640 --> 00:29.320 is our home page promoting Blue Sky the social network. Blue Sky is big world social. It's 00:29.320 --> 00:33.520 a model you're probably familiar with and probably had opinions about. Blue Sky is the 00:33.520 --> 00:40.000 company I work for, but is Blue Sky their main product. I don't know. See that app 00:40.000 --> 00:45.000 protocol part? We're mostly going to talk about that. You could say app protocol is the 00:45.000 --> 00:51.360 product. Will you at the end of this? Maybe. This is the landing page for our new 00:51.360 --> 00:57.280 app protocol doc site. It's not quite live yet. It should be live this month, but I can 00:57.280 --> 01:03.680 show a live version right here. We've got this night globe that we can rotate. It's very 01:03.680 --> 01:10.080 neat. CTO did that. He loves it. If we scroll down, you can also see some really neat 01:10.080 --> 01:14.480 new landing page features. You can see an app protocol lexicon, which we'll talk about in 01:14.480 --> 01:19.160 the second. You can highlight some of the components of this app protocol lexicon, so for 01:19.160 --> 01:25.920 example, strong typing, hyperlanking, with checksums, some very neat features. If you keep 01:25.920 --> 01:31.520 going, you can also just stream some public posts at records from the fire hose right 01:31.520 --> 01:36.840 here on our homepage. Pretty neat stuff. I am a docs person by trade generally. I've been 01:36.840 --> 01:41.040 working on these new docs since I joined the company about three and a half months ago, 01:41.040 --> 01:45.440 and I'm really excited. They're going to launch pretty soon. The app protocol is the most 01:45.440 --> 01:49.000 important part of what we're doing. It's what distinguishes Blue Sky from other big world 01:49.000 --> 01:54.320 networks and also from other default small world or default community forward decentralized 01:54.320 --> 01:59.760 networks. Over time, you'll see more of our docs presence reflect the app protocol and 01:59.760 --> 02:04.960 less Blue Sky. This will be the first big change. You'll see in that department probably coming 02:04.960 --> 02:10.400 in just a couple of weeks. I'm going to use this not yet live version of our docs site. As 02:10.400 --> 02:14.240 a way to structure my talk, so you can see some of our new features, what's coming soon, 02:14.240 --> 02:20.320 what's exciting here. So take a look here. We'll start out showing you how to perform read 02:20.320 --> 02:24.880 and write operations. This is actually very novel for the app protocol docs. Up to now, 02:24.880 --> 02:29.520 we would have the Blue Sky docs show you how to make it get, how to make a post. But kind of 02:29.520 --> 02:34.320 driving at the core app protocol concepts of what's a record, how do I get and post an 02:34.320 --> 02:38.160 app protocol record? Why is that important? How does that fit into different app 02:38.160 --> 02:43.360 protocol applications? That's a new thing for us. So we're trying to show not just higher level 02:43.360 --> 02:48.960 SDK abstractions, but make it easier to understand our core primitives. Among other things, 02:48.960 --> 02:54.240 this will actually improve LLM tooling for our docs. When Cloud goes and scrapes our docs, 02:54.240 --> 02:59.520 and generates code samples, having this laid out more clearly, more human readable, 02:59.520 --> 03:04.880 also makes it more machine readable. Good stuff. Makes it more generic, more reusable. 03:05.760 --> 03:10.560 For those who are new to app protocol, one of the most important concepts is our PDFs, 03:10.560 --> 03:15.280 personal data server. PDFs are where user accounts are actually hosted. They're actually an 03:15.280 --> 03:20.160 individual SQLite repose per user and Merkel search trees, which is very, very neat. 03:20.160 --> 03:24.160 If you ever read the fly IO blog, they're really good at talking about SQLite tooling, 03:24.160 --> 03:29.040 all the cool things you can do with SQLite. You can host the PDFs on your own. The PDFs is 03:29.040 --> 03:34.240 probably the easiest part of the app protocol stack to self host. It's the part that the most 03:34.240 --> 03:39.920 people are excited about self hosting, because when you self host your PDFs, you own your own 03:39.920 --> 03:43.760 data. You can host your PDFs wherever you want, whatever jurisdiction you want, under whatever 03:43.920 --> 03:49.040 terms you want, and if you don't want to host the PDFs, if you just want to sign up your account 03:49.040 --> 03:54.320 with BlueSky, you wind up on a BlueSky managed PDFs. BlueSky manages lots and lots of PDFs 03:54.320 --> 04:00.000 behind the scene. Many other app protocol applications also run their own PDFs. The PDFs is a 04:00.000 --> 04:05.760 very self-contained, very durable concept. We have our reference implementation that we ship in 04:05.760 --> 04:12.240 TypeScript, that we have a Docker installer for, but there are also PDFs written in OCaml, Rust, 04:12.960 --> 04:20.240 PHP, lots of PDFs is out there. PDFs can proxies some app protocol requests. For example, 04:20.240 --> 04:25.360 around Login, and so a lot of the time you are making requests directly to a PDFs, we'll get into that 04:25.360 --> 04:32.640 a little bit later, especially for private data. If you want a self host to PDFs, we've got our 04:32.640 --> 04:38.800 deploy script right here on the PDFs repo, that is linked from our new docs, uses Docker by default. 04:38.800 --> 04:45.280 It's got pretty low requirements. All it has to do is store your own local data, and that grows 04:45.280 --> 04:51.680 relatively slowly as you'll see in just a bit. We also have brand new this deploy recipes repo. 04:51.680 --> 04:55.760 I created this because when I was going through after I joined BlueSky and looking at all the 04:55.760 --> 05:01.280 open issues and PRs on our PDFs deployment, a lot of them were like, hey, can you support 05:01.280 --> 05:09.200 deploying this on Arch Linux? By the way, I use Arch sometimes, not this Mac, but I have used 05:09.200 --> 05:15.680 Arch in the past. Pac-Man, great package manager. I love the artworks. Credit established. 05:16.480 --> 05:20.880 But there's a lot of things that you can't really support upstream very effectively with a wide 05:20.880 --> 05:26.320 PDFs distribution, and so for that, I wanted to create this repo for user-contributed PDFs 05:26.320 --> 05:30.800 deployments and for deployments for other parts of our stack. Right away, we got a bunch of 05:30.880 --> 05:36.080 interesting stuff merged in here. There is a script for deploying PDFs to your 05:36.080 --> 05:41.200 synology mess, which is something that I might actually use myself. I thought that was quite cool. 05:41.840 --> 05:47.520 There is a deployment of our relay, which I'll talk about later. That's part of the big world 05:47.520 --> 05:52.880 indexing using Docker, and there's also a pop-man configuration, lots of cool stuff. That's 05:52.880 --> 05:59.920 relatively new. Take a look at it. When you install a PDF, you get a health check endpoint, 05:59.920 --> 06:04.320 you can hit your browser that just renders some text. That's really cool. That says at Prodo. 06:05.360 --> 06:09.680 But it doesn't actually give you much of a browser-based management interface. 06:09.680 --> 06:13.680 This is something we're looking at improving this year. We want to give you more ways of being 06:13.680 --> 06:18.880 able to administer your own PDFs. That way, you can deep dive into it. Maybe some 06:18.880 --> 06:23.920 profana dashboard, some additional features so you can really see. How am I scaling? If I'm offering 06:23.920 --> 06:28.960 this service to my own community of users, if I'm offering my own local infrastructure, 06:29.040 --> 06:32.560 for a lot of people who want their account on my server for some reason, whether it's 06:32.560 --> 06:36.320 jurisdictional, some other reason. We want to give you more insight and more tools there. So that's 06:36.320 --> 06:43.120 coming relatively soon. In the meantime, we've done a lot of work on our Goat command line tool. 06:43.120 --> 06:47.920 Goat, by the way, is just Goat. I can't believe that wasn't taken at home, or ready. It's just 06:47.920 --> 06:54.320 right. It's a good one. It's Goat. The Goat, coming soon from universal pictures. It's like a 06:54.320 --> 07:00.640 basketball playing Goat movie. I saw it in the train here. Goat is the At Prodo command line tool. 07:00.640 --> 07:06.000 It is very good right now for administering PDFs instances. For migrating your account across 07:06.000 --> 07:14.880 PDFs is a first order act you can take within the At Prodo ecosystem. We're big on a credible exit. 07:14.880 --> 07:18.720 And so if you ever have to migrate your account or interrogate what your PDFs is doing, 07:19.280 --> 07:22.720 Goat is coming along. I highly recommend taking a look at that. 07:23.600 --> 07:26.800 Now I'm going to move on to talking about some other aspects of At Prodo in this talk. 07:26.800 --> 07:30.400 If you're familiar with At Prodo on Blue Sky, some of these will be a review, but we have 07:30.400 --> 07:35.280 new work to share from all of them. So let's start with the FireHopes. FireHopes how you get data 07:35.280 --> 07:39.200 from the network. We talk about this pretty often, but it still bears repeating since it's 07:39.200 --> 07:44.400 unintuitive to other networks. All At Prodo call data on the FireHopes is openly available. 07:44.400 --> 07:50.160 You do not need to log in to access it. It is just a web socket. This is really really cool 07:50.160 --> 07:56.240 when in 2012 I worked for a company that had Twitter FireHopes access, which they 07:56.240 --> 08:01.040 had to negotiate through very complicated data broker agreements. They had to have their own 08:01.040 --> 08:05.520 complicated way of mirroring the data, being able to go back in time and query historical data. 08:05.520 --> 08:10.400 I had to write Hadoop queries in the job I had at that time to be able to read the Twitter FireHopes 08:10.400 --> 08:16.240 data. Who remembers Hadoop? Anybody? Yeah. Okay. So that used to be harder. And now it's not, 08:16.240 --> 08:22.240 which is really nice. Anybody can just connect to a web socket. Just like on our homepage and get 08:22.240 --> 08:29.920 data out of the At Prodo FireHopes. I showed it on the homepage just now. I can also show it in a 08:29.920 --> 08:36.160 terminal here really quickly. So I'm just going to pop open a new tab and let's try it. Okay, 08:36.160 --> 08:45.280 here's some syntax for getting out some FireHopes data. I'm going to pull it up here, grab it from the 08:45.360 --> 08:51.680 docs really quickly. You can't see what I'm doing, but that's okay. I'm just going to bump 08:51.680 --> 09:02.080 up on the bottom streaming data. All right. We use this right here and we're going to have some 09:02.080 --> 09:17.200 data coming out just a second. Okay. Here's my terminal window. You took a second to Boots 09:17.200 --> 09:25.040 for that. I'm sorry about that. We can hit this. And there are records. If, for example, 09:25.040 --> 09:29.600 I wanted to build an application on top of the At Prodo FireHopes, although that would be 09:29.600 --> 09:33.680 pretty much what I needed to do to do it. I'm just using web socat, by the way, which is a nice 09:33.680 --> 09:38.480 command line client for getting web sockets, and you can see that same record structure coming through 09:38.480 --> 09:47.840 there. Talk more about why all that is cool in a second. Backfilling is a concept that's 09:47.840 --> 09:53.200 related to the FireHopes, but it's also fairly unique to At Prodo. If, for example, you are the 09:53.200 --> 09:57.920 company I worked for in 2012 that was trying to offer historical Twitter FireHopes data, 09:58.000 --> 10:03.360 you had to figure out some way of capturing that data at scale and then having an accessible 10:03.360 --> 10:08.320 network and your own replicas that you could then use to query over time. That was very complicated 10:08.320 --> 10:13.040 to do. If you were an academic doing sentiment analysis or some market research firm that wanted 10:13.040 --> 10:18.160 access to that FireHopes, if you wanted to embed it in your Bloomberg terminal or whatever, 10:18.160 --> 10:21.840 you needed to have some way to be listening to the FireHopes and backfilling that data all 10:21.840 --> 10:25.440 along. You don't want to have to have real time requirements for keeping up with all the data 10:26.320 --> 10:31.520 that was hard to do. With At Prodo, one of the core goals is anybody can always backfill a whole 10:31.520 --> 10:37.360 copy of the network. That will always be one of the core credible exit principles. Anybody can just 10:37.360 --> 10:43.520 get the entire corpus of At Prodo records with enough disk and time. Right now, I think if you 10:43.520 --> 10:48.560 want the blue sky post, which are by far the most common type of record in the network, 10:48.560 --> 10:53.120 it's probably about 30 terabytes worth of those, so that's quite a bit of a hot disk provision, 10:53.120 --> 10:58.400 but for using any other kind of At Prodo record, any other kind of lexicon, it's way smaller. 10:58.400 --> 11:04.160 You can do it right now. Backfilling and cutting over to streaming new data, until recently was 11:04.160 --> 11:08.960 pretty tricky just because having to manage the cut-over between historical data and new data 11:08.960 --> 11:13.120 coming off the web socket, that was not nice. We recently released this application called 11:13.120 --> 11:18.480 PAP that makes that cut over much easier. PAP is now like a one-stop shop for any of that backfilling 11:18.480 --> 11:23.280 you want to do. TAP itself is written and go. You can just clone down the repo and run it on your 11:23.280 --> 11:28.640 own. We also have a TypeScript client and an interface to tap, so that way any time you have to 11:28.640 --> 11:34.960 get any data from the fire hose, you can just do so this way. That's really useful for example 11:34.960 --> 11:39.920 for creating custom feeds. Creating a custom feed of At Prodo data really just involves listening to 11:39.920 --> 11:45.120 the jet stream listening to the fire hose, pulling down some subset of records that you want to 11:45.120 --> 11:52.160 include in your feed, filtering and then rebroadcasting at a feed endpoint. TAP makes feed creation 11:52.160 --> 11:57.840 much more straightforward. One of our earliest code patterns is this feed generator sample. We've 11:57.840 --> 12:03.520 got commits here going back three years to back when At Prodo was brand brand new. I recently 12:03.520 --> 12:11.680 rewrote this and let me see where the browser window I put as a feed generator sample. That's now like 12:12.560 --> 12:17.680 200 lines along for the entire thing. Much, much, much, much more straightforward. We're always 12:17.680 --> 12:22.800 trying to improve what you can do with At Prodo. Make our patterns cleaner, modernizer integrations, 12:22.800 --> 12:27.680 and TAP is a big part of that right now. For those of you who want to be able to do a feed without, 12:27.680 --> 12:32.400 you know, actually shipping your At Prodo feed generator, there are applications like Gray's 12:32.400 --> 12:39.200 not social. Gray's not social's whole product is you can build no code custom feeds for a given 12:39.200 --> 12:43.600 event, for a given media purpose, whatever. They got some really good coverage during the 12:43.600 --> 12:48.400 New York mayoral election a few months ago because they had a custom feed. That was embedded in 12:48.400 --> 12:54.880 media coverage. That was getting that data. Now, what if you don't want to have to backfill 12:54.880 --> 12:59.040 records? What if you don't want to have to download all that content with TAP? That's a lot of trouble. 12:59.040 --> 13:04.640 We don't want to have to do that all the time. Good news is a solution and it was written in 13:04.640 --> 13:12.640 Rust. Yeah. There you go. I thought so. This is the microcosm tooling. Microcosm is a set of 13:12.640 --> 13:18.960 open APIs that index all the backlinks in At Prodo call to enable very, very, very fast queries. 13:18.960 --> 13:23.440 There are a lot of questions you can answer with backlinks. In fact, most of the look-up 13:23.440 --> 13:28.240 most people want to do when they're building some kind of data analysis on top of At Prodo, 13:28.240 --> 13:33.120 you can do that just with backlinks alone. If you go to the constellation landing page, 13:33.200 --> 13:39.680 currently indexing 11 billion links that exist in At Prodo call records. And when I talk about 13:39.680 --> 13:46.400 links, these are basically all the edges in that social graph can be conceived as a backlink of 13:46.400 --> 13:51.680 one form or another. So for example, how many people like to post who are all the blue sky 13:51.680 --> 13:56.800 followers of an identity? What are all the replies to a given submission? What are all the sources of 13:56.800 --> 14:01.600 links to any given record? Well, when everything is a record, it makes it pretty easy to represent 14:01.600 --> 14:07.680 all the edges as backlinks. And so you can very easily build on top of this to answer a lot of 14:07.680 --> 14:14.960 questions. One of the best interfaces for browsing any kind of At Prodo data right now is an interface 14:14.960 --> 14:21.600 called PDSLS. Everybody on the team uses PDSLS. We just love PDSLS. It makes visualizing everything 14:21.600 --> 14:29.840 we do significantly easier. And the best part is we didn't build it. This is made possible entirely 14:29.840 --> 14:35.120 by community developers building on top of the backlinks that you get from microcosm. So if I look 14:35.120 --> 14:40.880 up my own identity right here, I can now click through on any given post I've made and I can just 14:40.880 --> 14:46.880 see the raw protocol data. With all the different attributes, I can click through. I can even look 14:46.880 --> 14:55.040 up the Alexa con. The schema for the post itself is also just another record here in the back 14:55.040 --> 15:00.080 links. And this is all just being resolved instantly because it doesn't really have to do any 15:00.080 --> 15:08.240 lookups. Very good stuff. It makes a lot of our lives easier and happier. Now we'll talk about 15:08.240 --> 15:13.680 Alexa con's briefly. I keep mentioning Alexa con's in passing. When I talk about blue sky records 15:13.680 --> 15:17.760 being just one type of Alexa con, Alexa con is a schema system used by the At Prodo call to define 15:17.760 --> 15:23.200 different RPC methods and record types and provide interoperability. Applications like 15:23.200 --> 15:28.880 loose guy need a way to describe their own behaviors and semantics. Right? At Prodo is not designed 15:28.880 --> 15:34.320 for blue sky. Blue sky is merely one set of Alexa con's one application, one kind of records. 15:34.320 --> 15:39.760 Blue sky uses some of its own Alexa con. So for example, at.beesky.feed.post is a lexicon. 15:40.880 --> 15:46.960 Really cool thing about how all of our HTTP API methods work. We have what we call XRPC, 15:46.960 --> 15:54.240 which is short for lexicon RPC, which is just HTPS. And the way that we design all of our endpoints 15:54.240 --> 16:00.880 and as well as all of our permission sets in OAuth and all of our record formats is all the same 16:00.880 --> 16:07.120 thing. You define it all through lexicon's. And so you can tell, for example, if you have a given 16:07.120 --> 16:11.600 at record pipe, that's going to be the same permission you request. That's going to be the same 16:11.600 --> 16:16.320 record structure. That's going to be the same endpoint. And so for example, you have an app that 16:16.320 --> 16:22.160 uses app.beesky.feed.post, that's going to expect in any given app that implements it to be able 16:22.160 --> 16:29.680 to hit an endpoint like post, you know, XRPC slash app.beesky.feed.post. And with your post contents. 16:30.880 --> 16:35.680 A really neat thing about this as well as it means that the way that you get and post data 16:35.680 --> 16:42.080 to and from at Prodo call applications is the exact same way that data is stored on the PDFs. 16:42.160 --> 16:47.200 So your gets and posts just turn into gets and posts on the server. And that can be your 16:47.200 --> 16:52.560 own server where you're hosting your own records. It's very transactional. It's very transparent. 16:52.560 --> 16:57.360 Nothing goes into a database in a different format. Nothing is ever really serialized and 16:57.360 --> 17:01.760 desirialized away from your own data. It's just the gets and posts to just stuck somewhere. 17:01.760 --> 17:07.040 And we can build an entire application ecosystem on top of it. We have some new cool CLI tooling 17:07.040 --> 17:10.320 for working with lexicon. You have brand new TypeScript SDK called Lex. 17:11.200 --> 17:14.400 When you're bootstrapping a new project, you can use Lex install to fetch 17:14.400 --> 17:19.200 lexicon as you want from the lexicon repository. Then use Lex build to generate TypeScript 17:19.200 --> 17:26.560 types for them. And that is how you get first order SDK methods for any generic lexicon. So that means, 17:26.560 --> 17:32.560 again, blue sky is not special. If you want to have nice SDK primitives that call a method on 17:32.560 --> 17:37.280 a given lexicon, write the lexicon yourself, compile it, push it up. There you go. 17:38.240 --> 17:42.880 On the go side of the shop, we also have goat. You can use goat to went your lexicon's 17:42.880 --> 17:47.520 and to publish any new lexicon's you've just written to your own PDFs from which any 17:47.520 --> 17:53.520 world can install and build them. We've also got a big long lexicon style guide for anybody who 17:53.520 --> 17:57.200 wants lots and lots of recommendations for how to format their new lexicon's for their apps. 17:57.200 --> 18:02.800 And other developers are building their own interfaces for browsing the ecosystem of lexicon's. 18:02.880 --> 18:07.760 So you can see, again, all those different parameters in a nice web, 18:08.960 --> 18:14.800 viewable interface. There are lots of non-blue sky lexicon's being used in the ecosystem. 18:14.800 --> 18:20.480 I really like leaflet.pub, which is just a long-form blogging site that is built on a separate 18:20.480 --> 18:26.320 app. Prodote, uh, lexicon. I like this because I think that micro blogging and regular blogging 18:26.320 --> 18:32.000 are not inherently that far apart. I like the idea of integrating micro blogs as comments to a 18:32.080 --> 18:37.840 longer form blog and being able to store these records side by side is I think really cool. 18:37.840 --> 18:42.640 If you think about what I've already said about uh, backlinks and about the ecosystem of 18:42.640 --> 18:47.920 that protocol records, you can see how we can get it something that's kind of RSSC. Maybe once again, 18:47.920 --> 18:56.160 we're going to bring back RSS. The web's back. Yeah. Yeah. Yeah. I do a lot of regular writing about 18:56.160 --> 19:01.600 my uh, devra work on a leaflet right now. So for anybody who wants to follow that for new developments 19:01.600 --> 19:07.040 in that protocol, they'll be a link at the end. There's also, thanks to the power of lexicon's, 19:07.040 --> 19:13.280 some really cool third party clients that are maybe technically not blue sky clients. They're kind 19:13.280 --> 19:19.280 of in a secret third category where they're not entirely new app like a leaflet, but rather they're 19:20.080 --> 19:25.600 kind of like a game that makes browsing social media a little healthier because it gives you a 19:25.600 --> 19:31.120 stamina level and you deplete your stamina by reading too many posts, which is how a lot of 19:31.120 --> 19:36.880 people feel about social media in real life. Uh, and and deep thing about that is if we go back 19:36.880 --> 19:42.800 to looking at PDSLS and we look at, you know, all the different lexicon's that I have interacted with 19:42.800 --> 19:47.120 because I've used different app photo applications that have written to my PDS. You can see, 19:47.120 --> 19:51.040 okay, here's all the blue sky lexicon's here are the core records for my posts, my likes, my 19:51.040 --> 19:55.920 followers, whatever, here are my leaflet publications like I mentioned, those blog posts, you know, 19:55.920 --> 20:01.840 there's a whole blog post in code of the do-app photo record, but for Anosota that Mothi app, 20:01.840 --> 20:06.560 that's got its whole separate set of lexicon's. You can use an existing set of lexicon's and 20:06.560 --> 20:13.120 defines a new one to make your application for a pick and mix. You can create new applications 20:13.120 --> 20:19.120 that build on the strength of that existing social graph. And that's going to bring me to my conclusion 20:19.200 --> 20:24.960 of this talk. Once I fix my window management, there we go. All right. There have been some pretty 20:24.960 --> 20:29.600 cool blog posts written about this ecosystem, talking about just exploring the app protocol. 20:30.320 --> 20:35.920 When I think about the social graph, when I think about those 11 billion edges that currently 20:35.920 --> 20:40.880 exist in the network, a lot of those are just building on this get follows relationship, 20:40.880 --> 20:44.640 which again, is pretty germane to how we've always thought about social media. It's big world 20:44.720 --> 20:48.800 social, right? You can use that existing follow or graph for anything you want, whether it's shared 20:48.800 --> 20:56.240 interests, communities, local, big scale, whatever. Any application you build on that protocol is 20:56.240 --> 21:00.800 already bootstrap with all those follow relationships. You can add any other application features, 21:00.800 --> 21:05.040 any record types you want, but that's a really good starting place to expand. There's been 21:05.040 --> 21:09.680 some really cool writing done by community members, former Blue Sky Team member Danny Abramov, 21:09.680 --> 21:14.320 this cool blog post recently called a social file system, which at the end of the blog post, 21:14.320 --> 21:21.680 he uses a fuse file system plugin to mount his PDFs as a local disk, and then he just has a 21:21.680 --> 21:27.920 bunch of JSON records that he's populated on his own file system, which his local clawed CLI can go, 21:27.920 --> 21:33.520 and then just re-all his posts and do some meta analysis from that. There's a lot you can do 21:33.520 --> 21:37.200 when your posts are just records and the whole thing is wide open. I think it's really cool. 21:37.520 --> 21:45.360 Finally, for the activity Pub developers who might want us here, I wanted to just briefly talk 21:45.360 --> 21:48.960 about the cool word Bridgy Fett is doing. I think we've already talked about that in this from 21:48.960 --> 21:53.040 this afternoon, Bridgy Fett exists, so we have some compatibility between activity Pub and 21:53.040 --> 21:58.720 at-product tooling. If you take a look at our numbers right now of the weekly users that are 21:58.720 --> 22:04.560 creating at-product records that are posting from non-Blue Sky PDFs, as you can see in the bottom here, 22:04.560 --> 22:09.600 green would be self-hosted PDFs, so you're running your own app, probably, LPDS. Everything that's 22:09.600 --> 22:15.120 not green on this chart is pretty much coming from the activity Pub ecosystem, and you can see 22:15.120 --> 22:20.640 we've got some pretty respectable numbers here. That's touching like 20,000 users a week or creating 22:20.640 --> 22:27.680 records from non-Blue Sky PDFs with their self-hosting art tooling or using Bridgy Fett. If you look 22:27.680 --> 22:35.920 about as a proportion of all weekly posting users, which is about 1.5 million right now, like 22:35.920 --> 22:42.720 give or take, it's around there. There's an internal debate that it's actually more like double this, 22:42.720 --> 22:49.040 if you have a better window to a survey, but we'll say that it's 20,000 out of 100, 1.5 million. 22:49.680 --> 22:53.840 That's about 1%, it's a little more than 1% of people who are not just using a Blue Sky 22:53.840 --> 23:00.320 PDFs to post, and that's like desktop Linux numbers. I feel good about that. That's a sustainable 23:00.320 --> 23:06.080 community. You can do a lot with a 1% user base of a very popular application model. I think that's 23:06.080 --> 23:13.120 going to go up. I think that's getting to sustainability. Why build on app? No need to architect your 23:13.120 --> 23:18.000 own data models, build on the existing lexicon supplement your own, and you save yourself having 23:18.000 --> 23:22.960 to make a lot of API endpoint implementation decisions because lexicon's are used for permissioning 23:22.960 --> 23:27.680 and for API endpoints and everything in between. Our code generation provides first-class support 23:27.680 --> 23:32.400 for all lexicon, so you can leverage that ecosystem's social graph. All records are basically just 23:32.400 --> 23:37.040 debts are posted exactly as they look like, and so it's really straightforward from a developer 23:37.040 --> 23:41.520 point of view. We've got a very engaged dev community lot of people building an app right now. 23:41.520 --> 23:46.080 You can self-host as much as little of a stack as you want. I barely in this talk talked about 23:46.080 --> 23:50.960 self-hosting non-PDS components. There's a lot more we can talk about there. If you want a use case 23:50.960 --> 23:56.000 that's low code, no code, or what I'm calling lots of code, like a little pizza chef, like lots of 23:56.000 --> 24:02.400 code. You can self-hear on use case, and protocol interoperability with big world scale. That is 24:02.400 --> 24:09.840 the pitch. Thank you very much. You can find me at alics.bysguide.team. I'm also on the Fediverse 24:09.840 --> 24:16.400 at exfielix-digit press club, from a past life. We have a conference coming up at the end of March 24:16.400 --> 24:22.000 in Vancouver, the 2020-6 atmosphere conference. Lots of exciting talks. Sick is still available. 24:22.560 --> 24:27.840 2020-6 will be the atmosphere. I'm sorry. 24:27.840 --> 24:37.840 There have gone time for a few questions. Yeah, sounds good. 24:57.920 --> 25:04.480 So ATs, the standard, is being discussed at the ITF. There was a working group session at the 25:04.480 --> 25:11.200 meeting in Montreal, back in November. That's a really interesting process because we've really 25:11.200 --> 25:18.160 scoped down the aspects of AT that we believe are like ITF level and not application level. So we're 25:18.160 --> 25:22.480 trying to make sure that it makes sense what we're giving them to turn into a standard. Really 25:22.480 --> 25:25.920 interesting ongoing discussion. You can check it out on the mailing list or we can talk about it 25:25.920 --> 25:33.600 afterwards. Yes. Some of these are questions to check and go. But you mentioned that 25:33.600 --> 25:41.360 McKinney is really important. Can you tell us how it can go? Do you go down? Do you have 25:41.360 --> 25:48.480 data changes because of things in no corruption? There's a lot that goes into that in terms of how 25:48.480 --> 25:52.640 our relay works to help you fetch different PDSs. Our relay handles love the indexing across 25:52.640 --> 25:57.040 PDSs. I would love to talk to you more after this session. We're going to be here 15 more minutes. 25:57.040 --> 26:05.200 I'll be here afterwards. Thank you. Yes, you're welcome. Yes. Private data win. Yeah. My colleague 26:05.200 --> 26:12.560 Matt too in the corner doesn't want me to call it. Yeah, give us a few months to a year. Yeah, 26:12.560 --> 26:24.640 it'll be this year. Yes, yes. Yeah, so right now, even though things are quite open in this time, 26:25.600 --> 26:29.840 yeah. The only one on the first point is provide a lot on the other side of the company to steal 26:29.840 --> 26:38.040 the new one or the biggest relay if you're not