AT: The Billion-Edge Open Social Graph

I'm Alex. A fun fact about me is I live about two blocks away from this conference venue. So I love coming to scale. It's very convenient. I get to wake up in my own bed, have breakfast at home, walk over to the conference, takes about 8 minutes. So that part feels nice. Uh I'm Devril at Blue Sky like Kloe mentioned and I'm here to talk about the app protocol. Now if you go to sky.social, that is the company I work for. That is our homepage promoting Blue Sky the social network. Blue Sky is Big World social. It's a model you're probably familiar with from the last 15 years of micro blogging, and you've probably got opinions about it already. Blue Sky is the company I work for, but is Blue Sky their main product? Arguably, no. If you take a look right up in the corner there where it says app protocol, that is the protocol that underlies Blue Sky. That is the novel part of doing big world social in 2026. And I'll get into why that is and why I feel that approtocol is actually our primary product. So this is the brand new landing page for our approto docs site. It went live last month and I'm really excited about it. I joined the company about 5 months ago and the first thing I did was ship these brand new app protocol docs. The app protocol is what distinguishes Blue Sky from other social networks, big and small, uh, and also from decentralized networks that exist along a different pattern. Over times, you're going to see more of our docs presence and our comms reflect the app protocol brand. We built Blue Sky first to have a product to ship the app protocol. Blue Sky is a social network. People still know us primarily as Blue Sky, but Approto is where a lot of our new docs live. It's where a lot of my Devril effort is going towards and it's what we're building the most right now. I'm going to use this brand new doc site as a way to structure this talk about what we're doing. Our new docs, if you take a look at the sidebar here, they start out by showing you how to do basic readr operations. This is really core to whatever you're doing. Obviously, it's also not something that was in the docs previously. That was only in the blue sky docs. And the blue sky docs primarily had higher level SDK abstractions, right? It's like okay I want to do something on this one existing network. Here we're taking a step back. We're talking about how to read and write at records. You know how do you just create records in this network following any particular model. We will want to make it easier to understand our core primitives which will among other things improve LLM tooling for our docs and emphasize which aspects of app proto are meant to be generic and reusable. Again not just by blue sky. For those who are new to Approto, one of the most important concepts for users to self-host and own their own data is our PDS or personal data server. PDS's are where the user data actually lives. Uh they actually live in individual SQLite repos laid out as Merkel search trees, which is super neat. If you want to see details of that, we can get into that later on. You can host a PDS on your own and you can migrate user data across PDS's at will. So you might have one person hosting a PDS server that's got a bunch of different people's data on there. They can migrate across PDS's. If you just signed up with Blue Sky, chances are that you are on a Blue Sky maintained PDS by default because a lot of Blue Sky users don't care about where their data live necessarily. They just want to be able to interact with the network. But by starting out that way, by starting out on a Blue Sky PDS, you can then go and take your data where you want to take it. You get a credible exit. You get the ability to own your data and a lot of the rest of our stack is actually designed to shift load away from the PDS to make it easier and less expensive to host that user data. So most of the architecture of the at proto is essentially you have the PDS that's the thing that's easy to self-host that's what actually hosts your data. You can take that wherever you want. It's SQLite. the entire rest of our stack which I'll get into and which you can find here on this dock set you know relays application views are all different layers to index that data and to make hosting your own data more achievable and more scalable PDS's proxy some app proto requests for example around login and we provide patterns for developers to help support user choice in this way you can self-host many other parts of our infra as well and this is covered in the new docs PDS are this part of the stack that Most people are going to want to self-host in most cases. And for that, we provide Docker deployment scripts. So you can find link from our docs on GitHub. The way to self-host a PDS in a pretty lightweight VPS instance, whether it's, you know, OVH, Digital Ocean, you've got a lot of options. PDS by itself is pretty scalable. We've got a reference implementation. We also maintain a separate repo of contributed deployments. If you want to host a PDS or a different part of our stack on non-standard infrastructure. Uh part of the reason I created this repo was in the first week that I was working for Blue Sky, I saw a lot of open issues on the reference PDS repo saying, you know, like I want to support Arch because we all love Arch Linux, don't we folks? >> Yeah. >> Yeah. Okay. Yeah. I have actually run Arch for many years myself. But I kept having to say like, hey, you know, Arch is not really the upstream default distribution. We're not necessarily trying to support Pac-Man out of the box on bare metal. So created this separate repo deploy recipe so that anybody who wants to contribute, for example, a way to run their PDS on a Synology NAS, which is super cool, uh can do that and we can maintain that. We've got a really cool community of self-hosters, people who don't want to use that reference PDS. One thing that we don't currently provide, in my opinion, that I would like us to do better on that we're working on this year is a web admin interface for our reference PDS. Our PDS implements all the endpoints that we expect it to. So that way you can interact with user data on a PDS, for example, using our Goat command line tool. But the PDS itself doesn't have a lot of a web backend that people might expect if they want to be able to go in for, you know, graphfanaometrics for any kind of like self uh data checkup, anything like that. Uh I'm kind of picturing like when I log into my Pi Hole on my own home network, we want to provide more of an interface like that behind a PDS on the web, like an admin dashboard. So that'll be coming soon. In the meantime, the reference PDS does implement all the expected XRPC routes back here. And we have Goat, our cool command line tool for interacting with the PDS in all the ways that you might want. I can't believe, by the way, that goat wasn't taken. Such a good name for a command line tool. It's goat. Like that's just that wasn't even in brew. We have goat in homebrew now because nobody had taken that. That feels like really kismmet for us. All right. Now, I'm going to talk about some other exciting parts of the stack. Uh, if you're familiar with our work, some of these will be review, but we have new work to share from all of them. So, this is all brand new for 2026. We're going to start out with the fire hose. Fire hose is how you get data from the network. We talk about this pretty often, but it still bears repeating. All at protocol data on the fire hose is openly available. There is currently no non-public data on the app protocol fire hose. It is all public. You don't even need to log in to access it. This is really cool. I worked for a Twitter data services startup in 2012, uh, 14 years ago now. And to get and rebroadcast Twitter data, we had to write Hadoop queries and we had to store it all ourselves going back historical like it was very very non-trivial to be able to get access to this data for research purposes, right? For universities who wanted to do social network analysis like figuring out how to actually get legacy data from a social network was really, really, really tough. and everybody had to mirror it on their own. The entire app protocol fire hose is on a websocket and one of our primary goals is that if it's ever not possible to mirror the entire network by yourself, we have done something wrong. And that is a core goal for us. Uh right now, if you really wanted to mirror the entire network, that would be like 20 terabytes of hot storage. That's not something most people are going to want to do. But you can just connect to that websocket and you can get data. For example, here's what that looks like. If I were to use a command line tool called websockat, which is pretty good for getting data from websockets. And if I were to say move my terminal window over here, and that's not how you full screen it by clicking on that because I'm looking not where I'm supposed to be looking. What do we think? Is this going to do it? I can't see that. Well, full screen. I could do like command option F, whatever. Web socat. Here we go. It term. That is the app protocol. That is all the data being printed out of a terminal. It's obviously pretty hard to keep up with. Um we could like pipe it to less or something like that if we wanted to make it a little bit more legible. But that's the data. Uh you can do that right now. I don't have any kind of like O built in. There are rate limits of course to make it more feasible, but that data is accessible to anyone. We have a concept called backfilling. And backfilling is conceptually related to the fire hose, but it's also fairly unique to the app protocol. Like I mentioned, this is not a trivial thing historically to be able to make all of your data back fillable wherever you want. Uh this is a core goal of ours. If you want any or all of the data on the network, you can get it. It's a bit non-trivial to do that. Obviously, like I mentioned, if you want to provision the entire network, you're looking at like 20 plus terabytes of hot storage. But we want to make it easier to people for people to get a subset of that data. There's a lot of data on the app protocol network that is not just blue sky post for example and I'll talk about that in a second. But if you want to get any subset of our data technically challenging part apart from provisioning storage is actually cutting over from backfilling legacy data to monitoring that websocket. Right? You need guarantees of at least once execution for being able to actually retrieve that data. You want that to work in a clean way where it cuts over from backfilling to monitoring new data coming in. We've got a brand new cool tool called tap that makes that very very easy. Tap is a command line tool. It has this guarantee of at least once indexing of all the data. It can stream individual repositories at a time. Like I mentioned a second ago, uh the PDS is kind of the core component of the network. most of the other parts of the approto stack are designed to just shift load away from the PDS. What this means as well is that a lot of the different parts of our stack implement the same APIs and the same endpoints. And so if you're trying to use tap to back fill all the data from a relay from the relay of all the data on the network, you can make that same API call to an individual PDS or an individual user account. And so if you wanted to back up just your own data, for example, not only is that not 20 terabytes, it uses the exact same tools, same code path, same tooling, it's just way more scalable. That's also a nice principle. We call it mushrooms the whole way down because everything's implementing the same parts of the stack. Another cool use case for tap is creating custom feeds. Uh we like to talk about obviously algorithmic independence, being able to dictate what you want to see, being able to not be reliant on uh large organizations pushing their content at you and not being able to dictate what's in your feed. You can make your own feed. What that entails basically is just listening to the fire hose with a tool like tap and then rebroadcasting posts from a specific endpoint after algorithmically sorting them the way that you want to. You can build a feed with our sample feed generator patterns that make this pretty straightforward. We've got a feed generate tutorial featured on our new docs or you can use one of the many other products that are building on top of at proto like gray social whose entire product is a feed builder interface and feed hosting. So that way you don't have to do all that work of implementing the back filling and the rebroadcasting and the algorithm on your own. They'll give you a visual tool for doing exactly that and for hosting it. Now, what if you don't want to have to backfill all the networks to all the records to be able to build on top of app proto? There's also a really cool solution for that. It is also community developed and it is written in Rust. Yeah, it's nice to know your audience. Those are really easy applause lines. Uh this is the microcosm tooling. Microcosm is unbelievably cool uh built by a community member and this is a set of open APIs that index backlinks from the app protocol to let you perform very very fast queries on data that's already in the network without having to do all the work of building out those complex queries yourself. There's a lot of questions you can answer with backlinks. So here's the landing page uh for constellation and this gives you the ability to find any record that's linking to another record. Well, this is really cool because a follow relationship is linking to another record by expressing a follow, right? That is one link to another. The semantics there, if you've ever done like semantic web stuff, it's like okay, subject predicate object. That's a link. That's a backlink you can just get immediately. A like is a backlink. Any post responding to another post is a backlink. Any post that's embedded in a blog on app protocol is also a backlink. And so you can find lots of creative ways to query the existing data without having to do that big backfill. We have as of um actually I made these slides about a month and a half ago probably more now but over 11 billion back links from the records already on the network. So that's where the title of this talk comes from billion edge social graph. There are so many ways of interrogating the data that we already have uh to answer complex questions just by looking at which records relate to other records and we can do that in a really lightweight way because all the data is publicly indexed by relays. One of my favorite uses of backlinks is this data browser PDSLs. PDSLs also a community tool lets you open up any given app protocol record or account in a browser. So that way instead of looking at some JSON in a terminal, which is fun for some of us, but not all of us, you can click through and see where all those different records are linking to one another, and you can navigate directly from a post to the person who posted it, to somebody they follow, to somebody they're replying to, or to the definitions embedded in those records themselves. Uh, PDSLs implements some direct PDS API calls. It also implements backlinks. And by doing that, it becomes a very powerful way to navigate the network in primarily a front-end tool. Really robust big world social protocol tooling. It's all open. A lot of it is communitydriven. Makes me very happy. Now I'm going to talk about another key part of app proto lexicons. Lexicon is a schema system used by approto to define RPC methods and record types and provide interoperability. Approto apps like blue sky need a way to declare their own behaviors and semantics. Lexicons solve this while making it possible for developers to introduce their own schemas. So there's nothing first class in the protocol that is built for blue sky. Blue sky is built on top of the protocol. Blue sky defines its own lexicons like a post for example and it implements that on top of app proto. That's why when you talk about reads and writes, we're just talking about reading and writing different kinds of at proto records. Those are the generic. It's just a record. And Blue Sky uses a certain set of schemas to be able to define record types and then define API methods that you can use to create or read those record types. App.bsy.feed.post is a lexicon. It's quite a commonly used one, but it's not the only one. And you can just push up your own. uh all the API methods are scoped and implemented using a particular set of lexicons. We've got an API system that we call XRPC short for lexicon RPC that is just HTTPS. Any app using that app B sky feed postre record type would be expected to implement an endpoint again defined by a lexicon that also supports reading and writing those records. Everything's lexicons the whole way down. That way you can build your own app very easily, either by reusing the existing data from existing lexicons or by writing your own new lexicons. We've got some cool new CLI tooling for working with lexicons. Uh we just rebuilt our TypeScript SDK. Notice how I didn't pause for applause at TypeScript unlike Arch or Rust. Again, know your audience. Uh, but we just rewrote our TypeScript SDK and it's all built around this new tool on the command line called Lex. Lex is used for code generation from the lexicons hosted in our existing repositories or any repositories that you push up. You can run lex install to bootstrap a new project to install new definitions from existing lexicons and then just lex build to build types from those lexicons to be able to just automatically import into a project. And again, we're trying to make this very, very generic. A lot of our existing SDKs, you know, had blue sky methods defined and there were non-blue sky methods. We're moving away from that. We're making everything codegeneration forward, lexicon forward, so that if you want to have first class support for your lexicon for your app, you can do that. On the Go side of the shop, I mentioned Goat, which is useful for interacting with PDS's to give yourself kind of an interface to where you're hosting that data. Uh you can also use goat for authoring lexicons and for linting lexicons. So these are all expressed just in JSON. And when you do goat lex publish you're just pushing a lexicon definition up to your own repository the same way that you would push up a post by interacting with the blue sky network. So, we've got Go, we've got Lex, uh, really cool new tooling, and we're also making the Go SDK, uh, code generation routes a bit cleaner, too. Those are coming soon. We've got a Lexicon style guide for those of you who are really interested in building applications on the app protocol. We have a very, very long list of specs. If you scroll down this sidebar on appproto.com, you'll see lots of core specs. Uh, data modeling is really fun. I really like this part of the job because you spend so much time working with data models somebody else already put forward. And one of the cool parts of Approto is we do help. We have like a very batteries included approach to data modeling where if you just define something in a lexicon then you already have some clues about how you want to push it into a database. Right? It's like your gets and your posts are exactly the same thing as what you're storing to begin with thanks to lexicons. But if you're authoring your own, take a look at our lexicon style guide. Another community tool, Lexicon Garden, that is a web interface to the existing lexicons in the network. This way you can browse and search without needing command line tools to do it. And you can also navigate throughout the existing lexicon so you can see exactly what's defined in there and what kind of data you're pulling down. This tool is also improving all the time. This is the example, by the way, of the pub.leaflet.publication lexicon. Leaflet is an app protobased blogging platform. Wow, cool. We don't just do short form writing, we do long form writing. Internet. Uh, Leaflet's really neat because it has very very good first class support for embedding blue sky post and follow relationships because they're just kind of consuming different kinds of app proto data. But I really like that we have this nice way of integrating, you know, really short form writing with long form writing. Uh, I know everybody misses RSS terribly. I'm also in that group. And by building back the infrastructure this way on an open protocol, I think we're going to be able to get much closer to an RSS style serialization model as we've managed than we've managed to in like the 10 years since Google Reader kind of killed the whole ecosystem. Like this is a really nice example of being able to interoperate with existing data sets. Yes, >> I'm very glad that accounts can just give you an RSS feed because I love RSS. >> Yeah, like it's really not that bad to just implement more roots once you have a network that works the way you want it to. It's just like, hey, request this data a different way. That wasn't so bad. It feels good. This is one of my favorite community projects to showcase. I do a lot of my own uh Devril blogging on a leaflet right now. So, if you're ever curious what we're up to, you want to read about, you know, how I went to Fostam or how I'm here, uh, I like to get people excited about long form writing, and I really like that you can go directly back and forth from one medium to another using app protocol records. In addition to apps like Leaflet, which are defining and building on brand new lexicons, you can also pick and mix the ones that are already in the network. For example, if you're making a new client to browse blue sky post to add additional features, you can combine long form and short form content or build like a new in between thing. There's this client I really like called Anisota, which is kind of like a third party blue sky client, but it also defines a bunch of its own new lexicons on top of the blue sky lexicons that it interacts with to make kind of a game out of browsing your social media. like you'll actually like have a health bar and you'll take damage by reading too many posts, which I think is a nice way to summarize how we all feel about this some of the time. And it's it's also a really fun experimental way to build on the network with the tools that already exist. Like you can get quite creative by just remixing the data we already have. And I would say if you look at the actual data models that Anod uses, it's like twothirds blue sky lexicons, one-third its own. That's really cool. That works really well. If you take a look at all the lexicons currently associated with the given identity, here is my account in PDSLS. You can see how accessible this data is. Uh like I've interacted with Blue Sky a lot, but I also have the Anoda lexicons, Stream Place, which is a WebRTC implementation on the network. Uh Wisp, which is personal sites, a lot of those leaflet lexicons, just really cool stuff. And we're really fond of saying you can just build things on the network as sort of like a an animating call to action. I think one of the AI companies I think stole that for a Super Bowl commercial. So we can't really say it like it was our idea anymore because nobody believes us. It's like oh open AI said it. But but you can just build things. And I think that's a really good principle to come back to. Like we want to give people the tools to be builders, to have fun with this network, to not be passive consumers of posts because I think that is responsible for a lot of people's negative feelings about social web and social interaction on the internet. And by going builder first, I think we support a lot more self-determination and empowerment than the last decade and a half of social has in a lot of the time. Now I'm going to close by talking about social graphs. I've been talking about this to some extent for the last 25 minutes already reusing data building on the existing network network effects but there are some community developers who are focused on this right now and I want to highlight that work. Uh we only maintain TypeScript and Go SDKs ourselves but there are a lot of great communitydeveloped SDKs in other languages. I actually just updated this on the site this week and I'm going to show it off real quick. This, by the way, is our extremely cool landing page for the doc site. It has an animating globe that you can drag yourself and it's asy and it's really neat. And you can also scroll down and we have an embedded fire hose just like I showed off with websocket that just runs on here. Very cool stuff. Had a lot of fun doing this. If we go to our list of SDKs, I've mentioned that we maintain TypeScript and Go reference implementations. There are also a lot of community libraries. We've got Python, Rust, community TypeScript library, Dart, Swift, C, Ruby, Zigg, Elixir, PHP for the real heads. And this is even an incomplete list. Uh there's a lot of community work on the network. So, for example, if you're more of a Python social network analysis person, there's lots of people who have been in that boat. I was doing it in grad school for a while, like 15 years ago. Uh, you can do that if you want to do this good oldfashioned social network analysis. Again, we enable that backfilling. We enable all these back links. We can answer these questions and you can get good data out of the network. Right now, we don't gate keep it whatsoever. Um, followers as a a follow relationship. That's just a blue sky lexicon. That is not like again a first class app proto concept. There's nothing defining followers as a key concept of app proto that is implemented in blue sky. But that is a relationship that carries a lot of interesting data with it and it's something that a lot of people intuitively understand in a social graph. And so when I'm talking about picking and mixing lexicons to build on your application, if somebody asked me, you know, like do you reuse the existing lexicons? How much should I make? what's a technically a new app before I have like a shipthesis thing going on here. You probably want to start with that follower relationship, right? Like that's really powerful. If you want to have a blogging app, use those follows. You know, build your blog app entirely new. It doesn't have to be at all identified with Blue Sky. We don't want everything to feel like an extension of Blue Sky. But that follower graph, that's pretty cool. And so if you are building your own video app on top of our existing network, for example, bootstrap it with those follows. that helps you get past the I'm doing this brand new thing and now I have to get users mindset and that's no fun. Uh I've talked a lot about how the way the PDS works. Again, they're just SQLite repositories that contain all of your records that have endpoints that let you access them and rebroadcast them, but deep down they are just your files. And so you can host your own PDS. You know, it's not just on someone else's computer. It's not just in the cloud. It's all of our stack helps to rebroadcast those PDS records. really easily and in a lightweight way. And somebody made a fuse plugin, a file system plugin for the PDS, so you can just mount all of your posts on a local file system, which is awesome, right? Because when you're just storing all your records in a SQLite database, in a PDS, you can do that. And so rather than having to like download all of your posts as a social graph export because you want to quit Twitter and you want them to email you a zip file that's like 200 megs that you're never going to look at, which I think many of us have done, you can just mount mount your PDS mount your PDS like a file system. That gives you a lot of power to do whatever you want with your own data from any number of apps. Again, not just Blue Sky. Um, for the activity pub heads in the audience, and I'm sure there are several, uh, bridged is a really cool tool that provides compatibility between approto and activity pub. So that way you can syndicate your data across both social networks. There are a lot of tools that are using bridged. When I look at our internal metrics, a really cool thing I've seen is that all like the professional social media marketer dashboards that I don't really interact with because I'm not like a professional social media marketer are built on bridged. And so you can see that the critical mass between activity pub and approto has really been useful for professionals and for companies that want a broader reach to get on open social. It's nice to be able to go further together when you help get to critical mass with the community. Um, I have some data that also speaks to that. If you're interested in digital sovereignty and you follow our ecosystem, you've probably heard about Black Sky, North Sky, Euros Sky. These are all different hosts that are implementing parts of our stack on their own. So that way you don't have to interact with Blue Sky infrastructure at all if you want to be able to interact with the network. That way, if you don't want to have to go through American servers or if you want to be able to keep your data in a particular jurisdiction or set your own expectations around moderation, you can do that with your own infrastructure. That is non-trivial. You know, hosting a PDS is pretty straightforward. From there, it gets harder, but it's possible. And we're doing everything we can this year to make that easier. And we're seeing a big big big growth in scale from other providers this year. This is going to be a really big year for self-hosters. If we look at the blue sky records, these are records in the blue sky lexicon, people who are posting coming from nonblue sky hosts. You'll see the majority of those are coming from bridge posts from activity pub. That is the blue chunk. So all of those are activity pub compatible bridgeifed uh extensions. You'll also see in green, those are self-hosted PDS's, people who are hosting their own PDS, not on Blue Skies PDS's. If we look at the label from this graph, that's like 20,000 total in a given day. And this is only as of January. I think it's actually gone up since that. If you compare that to this slide uh which is all weekly posting users which is like one and a half million people in a given week unique users posting 20K relative to one and a half million that's a little more than 1% of people who are currently creating records who are self-hosting in some way who are not on blue sky. Little more than 1% that's like desktop Linux numbers. That feels good. that's sustainable, you know, like that's enough. That's an ecosystem. That's enough to kind of take those headwinds and go build that critical mass together. And so I see that as stable, solid, increasing, and really exciting. And I want to see this graph have way more granularity to it this year. I want to be able to see all those users who are on their own servers implementing all their own tools for interacting with the Approto network. All right. So why build on that proto? You don't need to architect your own data models. Our SDK code generation provides first class support for all lexicons, not just ours. You can build on top of the existing social graph. You can get those follow relationships. All records are basically just gets or posts in practice. Got a very engaged dev community. You can self-host as much or as little of the stack as you want. Uh you can take a low code, no code, or lots of code. uh my term approach to solve for your use case. So if you're building a feed for example, you can use an existing SAS implementation on top of at proto like grace and we have protocol interoperability with big world scale. I know a lot of open social is very skeptical of this big world scale point. Like we're one of the only ones arguably who are still trying to do this big world scale piece in a way that we believe can be open and provide a credible exit from uh corporateowned social media and we're committed to this that that credible exit with the big world scale handinand is something that's very unique to Approto right now and it's something that I really believe in. So that is the end of my slides. Thank you. And I would love to take some questions. >> Hi. Um, how does the protocol handle uh PDS's which are uh not great on uptime say? >> Yeah, that is a great question. Our relays are responsible for indexing content across PDS's. And the relays currently do a lot of different internal futzing with rate limiting and all this stuff to help make sure that we're able to avoid any one PDS from causing traffic problems for the network, but still make sure that we're hitting the PDS again. So if we miss it a few times and the record broadcast doesn't work and if it comes back up, it can keep syndicating records. A lot of the issues I get opened on the internal PDS repo were like, "Hey, I seem to have detached from the relay. Like, how do we work on that?" I can show you actually. Um, I had a browser window open here, didn't I? Yes, I did. PDS, PDS, PDS, PDS. So, if we take a look down here at the very bottom of this readme, one thing that I was just able to add was um fixing a relay desync is something that comes up from time to time for whatever reasons. Like if the cursor desyncs for some reason, we want to give people the tools to fix that on their own. Like we're in the middle of improving our relays and giving people again more insight. That's why I want to have this PDS web admin interface. People can see whether or not they're actually coming up and being indexed where they expect to be. But we want to give more tools there too. Thanks for asking. >> Um, for like the coming year, what do you see as like major roadblocks and how the team can work around them for appro? >> Oh man, that's a great question. Uh, we really want to make self-hosting easier. And so, like I said, the PDS is pretty easy to self-host. Relays have recently gotten much easier to self-host as well because we released a new protocol improvement sync 1.1 that makes it so relays no longer need to maintain legacy copies of all the data on the network. So a relay can now just rebroadcast. It doesn't actually have to maintain like a full mirror of all the data. So you can run your own relay now and many more relays have come online which is super cool. Hosting your own application infrastructure. Um, so for example, Black Sky Social is building their own app. So that way you can interact with Blue Sky users without having to ever even touch Blue Sky the app. That's hard because that actually requires you to do all the things you need to do to serve an entire app, right? You have to build your own indexes, your own caching layer, your own CDNs and all that. And so we want to be able to feature and make it much easier to document what goes into actually building that application level infrastructure. That is a big big piece because that part is still challenging because shipping application infrastructure is inherently challenging. Something else um I just wrote the new docs like I said really pumped about the new docs. New docs have six or seven standalone tutorials on them. Half of those are ooth related and that is for a reason but I don't love it. Approto is really good as an identity provider and so we talk about you know like build your own lexicons integrate with our social graph even if you aren't all in on the social graph like being able to log in with your own app proto identity is really cool right you own your own identity you're not using Google or Apple as an o source you're using app proto your own pds as an o source that's really neat that's powerful people want to do that but oath is not fun is so not fun like if you look at all the use cases we talk up on our website. It's like build your own algorithm, cool. Build your own agent, cool. Write OOTH. No. And so we're really trying to make the the O primitives uh equal in uh implementation uh fun to their utility. And so that's something we're working on. I could go on, but that's just a couple things. >> Yeah. So, uh, can you hear me? >> Okay. So, uh, how do you guys plan on dealing with age verification? Because I know there's been a lot of talk about that recently. >> Oh, yeah. Uh, so we were, I believe, the first or very very like one of the first to comply proactively with an age verification requirement recently in Australia. And that caught people off guard because they're like, "Why is Blue Sky making me prove my age?" You know, like this is weird. And it's because a lot of the other providers, you know, like Twitter, other companies, they're large enough they expect to be given a grace period by governments in a way that we don't take for granted because we're very small. And when a regulation comes in, we comply with the regulation. Discord recently ran a foul of this in a pretty serious way because they were the first I think uh social network to try to sell this to Americans which didn't go great. It's like a lot of people have been losing that battle in the UK over the last couple years and you've seen a lot more UK apps have to implement age verification because the government's been pretty straightforward just saying you have to do this. You know, I was in the UK on the way to Fostam 2 months ago and I had to do age verification to access my blue sky DMs, which is confusing to me. It's one of these things that we're not used to and I think we're hoping that the regulatory environment in this country is able to slow that down a little bit potentially. I know uh AOC gave a pretty effective speech in Congress just this week about why you might not trust neutral parties to be able to collect uh ID from users. Uh, right. It's one of those things where it's like, hey, you know, we see why this is maybe worth doing, but then who do you use for your third party ID implement? There's lots of potential areas for leakage there. We comply with regulations. The reason that people saw in Australia that Blue Sky was asking us to, you know, verify IDs is because we had to be proactive. We don't take for granted that we're going to be able to skirt regulations. Uh, but we would really like to be able to use trusted providers and like neutral parties to do that where possible. and we're paying pretty close attention to that conversation. >> So, are you are you >> are you actually collecting ID information in Australia or you are you pushing that off to a third party? >> We push it off to a third party in markets where we're required to. >> Have you seen a response from their citizenship? Are they okay with that third party or are they kind of revoling the same way we are and people in the UK and other places have? I think the UK for the most part has kind of accepted it in a way that Americans have yet to accept it. >> What about in Australia? Have they are they is there like is there provider already been caught a foul of like not like I guess keeping their promise of because all of them say that oh we're going to get rid of the data after x amount of time. >> Yeah. Not not to my knowledge but I agree with you. It's probably a matter of of when not if. Right. And and it's not great. And I would like to see the uh the public infrastructure for providers keep up with public requirements to collect this ID in the first place. I would like to see that shift towards a more neutral organization than currently exists for it, if we have to do it at all. >> Thank you. Uh on that same topic, how does age verification interact with self-hosting PDS's? >> So far, it does not. Um we've actually had a someone opened an issue from Euros Sky just a week ago to propose that we should put the age verification in the PDS and we push back on that for now saying that belongs to the application layer. We will see where that goes, but this is all very new. Well, I guess my question is really like it >> if I host my own PDS. Yeah. >> And then bridge to the main network or join the main network like is the main network eventually going to require that I somehow prove my identity or prove that I am following the regulations or something like that? >> I would say in the worst case scenario it would probably just be like one database flag that gets stored that is like has user passed verification in jurisdiction yes and there's not going to be any more associated with your account there. But again, I think we're currently thinking this doesn't belong in the PDS and it belongs in the app layer. >> Okay, >> we'll see where that goes. >> Uh, what do you think about hosting things that aren't really social or very much content on the PDS? Like, uh, one weird project that I've been thinking about is hosting DNS records in a PDS. >> Yeah. Uh, ignore the bootstrap problem of if your PDS goes down, you no longer have access to your PDS. Don't think about it. >> Yeah. >> Uh, we've had a lot of people talk like have similar ideas, right? The PDS is a pretty attractive model for just where you put your data. Like it's not quite a blob store. It's not quite a bucket, but we are doing work this year on permissioned data. So you can actually have ACL's in your PDS for data that you do not want to be rebroadcast everywhere. Right? The fact that the entire network is public right now obviously imposes some limits in the kinds of things people want to put in PDS's. But as our permission data model matures and you can read my colleague Daniel Homegrren's blog series about that. It's super cool. I think there is going to be more desire to just use these as generic data stores. And please do join that conversation because it's currently very open-ended. >> A followup to that, what's what would the impact be on the data infrastructure that you guys have to pay for? >> Yeah. Uh people eventually ask that question, right? They're like, "Hey, isn't this all fairly expensive?" And the application Streamplays, I think I mentioned, that's implementing like a WebRTC type solution on top of Approtos. They're trying to have like it's like Twitch for like a streaming solution for example. And I've talked to the maintainer of Stream Place right now. One of their ideas for how to collect revenue from paying users is to gatekeep the highquality video transcoding, right? And that makes sense because if you're paying for bandwidth, you're paying for bandwidth on a PDS. You know, right now everybody who posts a video to Blue Sky, it goes through 3 megabit uh H.264 transcoding. That kind of sucks. I've done a lot of video work. 3 megabit H.264 is not very good, right? Everyone complains like, "Hey, your video quality sucks." And I'm like, "Yeah, but for a reason." Yeah. Uh but again, if you wanted to have a service and you wanted to charge, you know, for like 20 megabit 4K H.265, like that's a pretty effective thing to try to gatekeep in your revenue model. You're not actually gatekeeping access to any data or features. You're just having someone pay you for storage. So, I think there's something there. And as people try to figure out, you know, like what a business model looks like building on top of all this open data, there's a lot of granularity. Is it too early to um have case studies uh to talk about like relationships that you had with governments um um like outside of the US where uh sovereignty is important to these governments? >> I would say it is not too early but a lot of those conversations are already happening in public. So, a lot of people are trying to get the EU excited about approto right now for good reason because it provides a lot of hooks into an audience that they want their message to reach and helps avoid a lot of the nastiness around the US government. Like those conversations are all happening in public and so I would just get involved and you know it's it's nice right when it's all just there but there's there's less happening behind the scenes than you think. It's all pretty much you know it's just there for you. Yeah. is it possible to host self-host any uh I guess private infrastructure using the AT protocol where you don't want to publish to in public or so a lot of the components do they share openly by default or are they able to be run I mean if you run them like offline in dedicated network is that possible or could they by natively be peer-to-peer within a private infrastructure There is no permissioned or private data on protocol yet. That is something that there will be shipping this year. We're currently in the design phase for that because a lot of people have asked for it. The way that DMs work in Blue Sky right now or the way that user preferences work. Uh those are just at the application level right now. those are not on protocol so to speak because we implement a lot of the same APIs at different parts of the stack which helps us again shift traffic load off the PDS for example we can use very similar you know API structures and just put the data in the app rather than in the PDS this is not a great model long term and we don't want to do that wherever possible which is why we're shifting towards putting permission data on protocol Thank you for all the wonderful questions by the way. I really appreciate the engagement >> for for permission data model. Um would it be poss like I assume that's both for reading but also is it for writing and how you can interact with records? >> Yep, sure is. Uh we we have a few different use cases. So we talk about you know like syndicating a a post that you want someone to have to be able to subscribe to or like a private group or all these different things. And you know some of them are harder than others. So we're trying to solve for a way that will address all of them. So you can have you know your private subreddit on app proto you can have your subscriber substack on app proto. You can have your group DMs and things like that. Uh part of my thinking is for example like um letting people write records into into your PDS kind of >> not quite arbitrarily but >> that is also being actively discussed right now. That's a big big can of worms. Yeah. >> Uh how would that work with different app views? Because the app view obviously needs to be able to access this private state this private data. >> How did would different app views have different access to private data? >> Well, sorry. How would this work with app views? you basically have to give your app view access to everything you have access to. >> So that's a good question and this is a long conversation. I would encourage you to read my colleagues blogs as he gets well into it. But what I can say is one of our earliest models for private data that we moved away from was having uh the app views like proxy all requests around permissions, right? where it's like you're only granting access to a private bucket to a particular app and everybody who wants to be able to access that same permission data has to do th do so through apps that have been granted permissions to it. We discarded that because we thought it got too appentric and away from the PDS as a model to a point and so we're working in a way to be able to do permission data that is not that appentric but yeah there's way more where that came from. Is there any uh talk about large file support or uh yeah >> yes we only use git lfs everyone's favorite tool. Uh so blobs are something that are allowed right now in the protocol. And so when you have like an image attached to a blue sky record, that's just a reference to a blob that's stored in the CDN. And we have a lot of different ways for proxying and handling blobs defined in our docs. Uh so we have a pretty graceful way of saying this blob is associated with this record. You can run like a sidecar service for video transcoding, which is what we do, and just have different endpoints that interact with the existing record structure. Records themselves are just JSON. Uh well uh the project you mentioned that was using a file system mount right >> yeah that's yeah >> does or do you know the constraints on what that supports currently and uh those are communicatable right not just for personal use >> yeah not off the top of my head >> or so can the things that are uploaded there they're shared right they're they're publishable >> so basically what you would do they it's all public data but the way the file system fuse plugin works to the best of my knowledge is it just implements like the PDS read write endpoints for your PDS that you can then go into.