AR.IO: A Scalable and Modular Gateway Built for the Permaweb

GM, GM everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for builders to showcase something they're working on or are passionate about in Web3. This is going to be an awesome project they've been working on, unit testing best practices, smart contracts, automation goodies, so on and so forth. Basically, if you've got a passion for something, this is your opportunity to share it with the Web3 community here. And today, I'm ecstatic that we're going to have David Whittington on from AR.IO. He's a member of the infrastructure team, acting as an infrastructure architect. If you didn't know, AR.IO is a scalable and modular gateway built on the Permaweb, atop the Arweave permanent data storage network.

So if you stick around for today's show, you'll learn how easy it is to run an AR.IO node Arweave gateway and see David walk us through some of its key features and architecture choices. All right, let's get into it.

Sorry, put myself on mute there. Welcome, David. Pleasure to have you on the show, man. Hey, happy to be here. Yeah, welcome, welcome. Yeah, really excited to learn a bit more about AR.IO. I know here at Developer DAO, we launched the series of academy courses earlier in the week, which have seen really great engagement and traction, and folks really digging into the Arweave ecosystem. So I think this is a great way to cap things off this week for people to get more of a deep dive and a chance for them to ask questions if they do. But I guess before we get into all the nitty-gritty details, maybe do you want to give a brief introduction about yourself?

Yeah, sure. So yeah, I'm David Whittington. I'm an infrastructure system architect working at Permanent Data Systems on AR.IO. Spend most of my time focusing on the gateways in particular. I'll talk a little bit about how the whole thing fits together. It's more than just gateways, but that's my area of focus. In the past, I've done things like work on satellite telecommunication systems, I did healthcare claims processing, some early infrastructure-as-code platform stuff. So I have a lot of diverse enterprise systems architecture background. And then I have a pretty strong interest and focus on databases and functional programming, which will be relevant as I sort of work through my slides. That's actually kind of what got me interested in this space to begin with, and hopefully that makes sense when I go through my presentation.

Awesome. Yeah, looking forward, man. I guess before we get into that, how long have you been in the Web3 space and Arweave ecosystem in particular?

Oh, yeah. So I think it was 2021 when I first got in, and I was not working on gateways initially. I actually started out by working on a decentralized mining pool, which I got pretty far on, never actually launched that because during that process I realized that gateways were a much higher priority thing for the ecosystem and sort of got in touch with the other people at PDS and just started working for them, initially part-time, and then I was like, let me just focus on this because this was really, I thought, the bottleneck for adoption. Mining is important, but not a blocker for anything. So that's kind of how I got where I am right now. And I guess it's worth saying a little bit about how I got into Arweave initially. In the last crypto cycle, I've been sort of passively interested in crypto for a long time, and when these cycles come around, it's like every time I look and it's like, what's happening? Is there anything real here? Because it always seems like there should be. And last time around, I looked at it and I was like, oh yeah, actually there are some pretty substantial real things happening. I just was looking around things. I think I saw YouTube videos, like Andreessen Horowitz YouTube videos of Sam talking about incentive structure, Sam Williams that is, and then saw Arweave, like permanent data storage. I hadn't even thought whether that was a possible thing. And when I looked at it, I was like, yeah, I don't think we're there yet, but it doesn't look impossible to me. And if you can build that, you can do a lot of interesting things. So I just, at that point, was like, well, I need to figure out some way to contribute to this because I think it's going to be very important if we can make it happen. And that's kind of how I got into it initially.

Awesome. Yeah. Yeah, sounds like a no-brainer decision for you. That's awesome to hear. And personally, I also started kind of in the Web3 space around the same time as you. I started with ETH and Bitcoin, but then once I found Arweave and the permanent storage, I was like, oh, this is pretty sweet. Coming from a backend engineer background myself. But anyhow, yeah, let's get into the content here. I'm really interested to see what you have in store for us.

All right, let me go ahead and share my slides. And for all of those watching today, if you have any questions for David, please be sure to get those in as comments or tweets, and we'll bring them up as we go along here.

All right, so getting into my slides here. It's just going to be an intro to AR.IO. You know, it's got a lot here, right? So I don't have enough time to go into fine detail on everything. But basically what I want to do first is, we already kind of did the intro about me, so I'm just going to skip that slide. But then I have a little bit about just what is AR.IO? Just really high level. And then I want to talk about why a little bit. There was a post I put on X the other day where I was talking about location independence, and I'll get into what that means in the slides. But the responses I got to that just reminded me, I was like, oh yeah, I thought about this stuff a lot a while back and came to certain conclusions, but not everyone goes through these things at the same speed or encounters things at the same time that I do. So it's good to just re-emphasize why we're doing some of these things and sort of how that motivates a lot of the structure of what we're doing and how we prioritize things.

So then after I talk about that, I'll talk a little bit more about what, you know, how things are architected, and then I'll do a little demo just showing like, okay, you're interested in this, how do you get involved and do things? And it's really easy to get started. That's the main thing I want to communicate there. It's extremely easy to just run a gateway for experimentation or, you know, to develop your own thing. Whatever you want to do, it's really easy to get started. Okay. So, we already did my intro, so I'm not going to talk about that. So really high level, what is AR.IO? Right? So it is an Arweave ingest, indexing, and access network. The initial protocol we have is mostly focusing on the access part, but it's really all of these things, and we're increasingly having all the components in place to sort of have a full stack here.

I will also say, I mean, hopefully the audience is familiar with Arweave, but I thought you never know who's out here. So Arweave itself is a permanent storage blockchain. That is what we are building on. I can't go into details about how all that works, but there's lots of other content out there. So that's the basis we're building on and we're building these things on top of it. And then in practical terms, what that is, is it's a protocol. So there's a token which has certain incentives around it. I'm not going to go into great detail about that in this presentation because I'm mostly focused on the software architecture, but that's a core component of this as well. And it's a bunch of open-source software. It's a gateway, it's an observer, and now we have an open-source bundler that's integrated with it too. And then we have this community of developers and operators. So people building on this and like, I think we have maybe like 200 gateways now. So there's a lot of people out there running gateways, which is amazing, you know, it's just great to see that. And the open-source part, really important in my mind. I grew up in the 90s, you know, when Linux was gaining adoption, and this is sort of like a core part of my values. So I'm just really happy that everything in this stack is open source. And I recommend, you know, even if you don't get involved in what we're doing, just that's very important that you have access and control over the software. So always check that on the things you're using. Okay.

So getting into why. So I talked about location independence just as a concept. I just want to go back and talk about the architecture of the web today. So currently, when you go to a website, you're going to, you know, go to google.com or wikipedia.org or whatever site, right? So that's a name. And what's going to happen is it's going to resolve to IP addresses, and the IP addresses are tied to servers. Now, you know, in the modern web it's a very complex set of things that happens. There's CDNs and all this, but ultimately, it's really just a set of locations, right? So you have names which are permissioned, it's like a permissioned database of DNS entries that map to locations. That's today. Where we want to get is values, so transaction IDs or content addresses. Both of these I think have good use cases, there's different trade-offs around which way you choose to address values here. And then we want a permissionless set of references to values. So our version of this in the AR.IO protocol is Arweave Name System (ArNS). There are others, but I'm here talking about our stuff. But anyway, we need something in this box, right, where you're resolving names to values. So that's the current state. Most everything is these locations with permission databases referencing locations, and we want to get to permissionless references to values. Okay.

Why do we care about this? So this is really like a core broken thing about the internet in my mind. When I link to something, I'm linking to that location, right? So I am at the mercy of whoever is operating that thing. And it's not like everyone's out to get you. Actually, there's a lot of work that goes into making permalinks and making the internet work despite this kind of broken information architecture at the bottom. So, you know, links can break, sites can go away, sites can be actively hostile, they can change things that you're linking to, and you really have no recourse. There are human organizations that put a lot of effort into maintaining things like the internet archive or the WayBack Machine, but that's kind of fighting the technology. There's no core technology primitive that you have to stop this.

So, you know, this means it's a thing we take for granted, but we shouldn't, right? When I have a site that has outgoing links, if I want to preserve those outgoing links, I have no way to do that. So there's basically no way to manage dependencies of your apps or sites in a sane way on the internet. This would be akin to you're building software and like you have no node modules directory. It just downloads everything on the fly. You know, you could think about how crazy that is, but that's basically the information architecture of the web. A side effect of this is apps do not really have credible exit. So I say very few apps do. I think we're starting to see that with like Farcaster or Bluesky. Some of these things arguably have some notion of credible exit where you could kind of leave the initial app and still have all your data with you. And this is a weird thing about the web. These days, again, we take it for granted but we shouldn't. It used to be that I would get say an Excel file, and yeah, Microsoft did all kinds of weird things with the format, but I could load this up in a bunch of applications. Was not a big deal for the common case. These days, the data is in the apps. We've coupled these things. You know, both for legitimate, like the tools we're building don't really let us decouple them. So it just happens, right? It's not like someone's out to get you. And there's like business model reasons. But this is a really big problem. We want to decouple these things again and being able to refer to values is how you do that because then as a user, you can preserve the values.

Okay. And this is a little thing I like to post on X periodically. Data is more important than apps, okay? If we have data that we can preserve and migrate across apps—and I shouldn't even say migrate because there shouldn't be any migration—it should just be like the apps refer to the same data, and you do that by referring to the values instead of locations. If we have that, the apps will follow, right? And what are apps? Apps are just data that you execute. So I really think we need to focus very hard on making sure that the data is based on these better information architecture primitives at the bottom, and then the apps will follow. You can always build new apps if you have access to the data.

All right, last 'why' slide before I get into a little more of the architecture things here about the gateways. Okay, so epistemology, the study of knowledge. It's maybe a little overblown to say that's really what this is about, but in some ways maybe not, right? Because like I said, I think the web has a broken information model. It is that way because of just historically how we got here in terms of the way the technology was implemented. It was efficient to do it originally this way. And it's a little bit like we're doing science without citations. So if you imagine you had a paper and instead of author's name and date and everything, the normal stuff you have for citations, it's like, it's on shelf Y in the library. You know, just imagine how insane that would be. We don't do that in science because we need to build on knowledge, and there's a lot of things that are less consequential than hardcore research on the internet, but it still really matters. You know, so that site that you look up that's like, oh okay, here's why, you know, you're on WebMD or something trying to figure out if you have cancer and like you want to refer to that thing and bookmark it and later it's completely different. That stuff matters, especially in aggregate.

And we see the same problem in programming, right? So this is what the problem that functional programming (FP) solves. Classically in programming, you'll have, you'll refer to locations in memory and then different things will change the locations in memory. If you have a bunch of different things going and a bunch of different people working on programming software together, it's really hard to know what's in that location in memory at any time. Like one process might be going, another process might be going, you might have different threads of execution, they're all banging on this thing, and then one of them comes in and looks at it, it's like, that's not the thing I expected, and then your program blows up. And so the way we've tried to solve this in programming is functional programming where you have values, you don't change the values, you produce new values. And we really want that in the large, and that's why I got into this whole thing in the first place. I think if we can change this in the large, it just accelerates and makes easier the production of new human knowledge, and that's extremely important for us as a society and civilization. All right, so that's a big picture stuff. I just wanted to go over that because I think I've internalized a lot of these things. Sometimes I talk about them and people are like, what are you talking about? It's like, this is the important thing that we get this right. And then there's a lot of how, right? How do you fund this stuff, how do you incentivize it, all that. That's all very important, but this is the underlying thing we need to fix and then a lot of things are downstream of that.

All right, so enough high-level stuff. Let's get into how does this gateway thing actually work? All right, so we had a white paper. Our white paper was written before the advent of AO, which is the new smart contracting thing on Arweave. So I took the diagram from our white paper and I corrected it very elegantly. At the top, we have the Permaweb, and that's kind of this notion of this web of things based on values and references to values. And then in between, we have AR.IO, and AR.IO is this combination of gateways and now even other things like bundlers and other stuff in that, but basically gateways and a smart contracting system, which used to be SmartWeave, that was sort of the OG smart contracting thing in Arweave. Now we have AO, which is basically better in every way. It's immature, you know, there's a lot of stuff to do, but the architecture is much better. And so we moved to that, that's our thing, and then beneath that is the storage layer, Arweave. So that's the 10,000-foot view of what's going on here.

Digging into this a little more. So thankfully, there's a lot of stuff on our white paper that didn't change, and this is some of that. So over here on the left, you have data readers and applications. You know, people can go directly to Arweave and read things by transaction ID or through ArNS names, or they may be building like applications infrastructure on top. So that's sort of the consumers, users of this service. And then in between, we have all these AR.IO nodes, and what are these? These are gateways. They're going to be talking to Arweave nodes to get data to index and serve to users, and then they're going to be talking to each other. So just recently we actually got the first version, very early still, of the peer-to-peer data sharing within the gateway network. Very important because Arweave is like this copy of everything, but your hot data is going to be much smaller. So you want to have a hot data cache in the gateways, and you want to be able to have them get that from each other. So within our network, the gateways are going to talk to each other, they're going to get the data. If they don't have the data, they can get it from Arweave nodes. And that's, you know, maybe this is like the 2,000-foot view or something. We're going to zoom in on the gateways next.

So what do the gateways work look like? This is really where all my effort goes into thinking about this, how we architect this well. Okay, so again, we have this communication with the Arweave nodes, then we have a gateway service. The gateway service is, it's all TypeScript/Express, pretty vanilla stuff. Like we try to make it boring technology as much as possible so that it is easy to work with and people can contribute to it and understand it. That said, there are some complicated things around indexing, but as much as possible, the boring path is good when you want people to adopt things and use them. All right, so inside the gateway service. This is where the sort of the modular and extensible stuff comes in. We have a bunch of different indexes. So we have an index of the chain, that's like blocks and layer one transactions.

By the way, I can tell already I'm going to go a little long, so just keep that in mind here. It's all good, all good. We have blocks and transactions, we're indexing them, that's the chain index. We also have a bundle index. So in Arweave, you know, there's the blocks and the transactions which are coming at roughly a block every two minutes and there's up to a thousand transactions in there. But then we have these bundles which are collections of data items which are basically, they're transaction-like things, they don't have all the same properties of transactions, but they let you scale beyond what the layer one could do for transactions. And so we have an index of that, then we have a data index. That is mapping the transaction and data item IDs to the data.

And we also do hashes, currently SHA-256, maybe in the future we'll do BLAKE3 as well. But that way we can do things like the same data could be actually in multiple transactions or data items, we can do some deduplication. Other things like if you want to verify things for trust purposes, you can use the hashes for that. And then last thing on there is we have this data store which is basically a cache. It's not going to be all the data in Arweave—though you could right now do that—but it's going to be the data you care about for your gateway, and then we'll be able to go fetch other things. So that's the big pieces that are inside the gateway, and we have implemented all these with interfaces such that we can implement different databases. So initially a lot of this is using SQLite as a database which has been great, honestly. I think the only thing I regret about that is I think sometimes people think SQLite means toy, it does not. You can scale SQLite a very long way. I'm happy that there's sort of a renaissance in SQLite usage now in production, because it helps with this management, it's like actually you can index the entire throughput of the mainnet right now of Arweave on SQLite, no problem.

So SQLite is in there for mostly, but we realize that you're going to need other things at some point and for different use cases. So someone from the community actually just came through and dropped a whole big Postgres PR. Now, whether we integrate that as is or like what exactly we do with that, I'm not sure, but it just shows that yeah, the interface is carved out such that you can do that. If you want to implement some other totally crazy database, you can do that and hook it into the system. And most of these things are implemented like that. So we just added S3 data stores for our own use cases for the data store and I expect more of that for all of these components. We wanted to start with the things that are very easy for people to run and for us to iterate on, so that's where we started and then we're going to expand out now that we have a lot of these things implemented fairly well.

All right. So getting into demo time. How can you use it? I dropped a bunch of links here. Our doc site is good, go there. Here's the link to the repo as well and there's a section in there—I think it's probably on our doc site too—about the environment variables, and everything is configured via environment variables. So you can check those out. If you don't grab them now, they'll be in show notes and whatnot too, so don't worry about it too much. Yeah, exactly. Then I will switch, I'm going to stop sharing my window and I'm going to switch to sharing my whole screen, do a little short demo just showing you how easy it is to actually start this.

Okay. All right, so hopefully you're seeing my terminal. Yes. Do clone. So I'm just cloning, this is all following stuff that's in our getting started guide, so you don't have to remember this, you could go look at our docs. I'm just going to clone the repo. Go into there. Not the backup I have in case things go south, but showing you everything. Local development environment thing, don't worry about that, it's not relevant to what we're doing. So I'm just doing a docker-compose up, that's going to start everything as kind of its default state. Running some migrations to set the database up initially. See a little warning there. There it is, interesting, which I'll have to look into later, but hopefully everything works. And you see we're starting to index the chain from height zero. So let it run for a second here, hopefully we get that. So what it's doing right now, it's going out and fetching the blocks. Fetching the blocks, and it tries to do some prefetching to optimize this, so once it gets going it's actually pretty fast, but it can take a little bit to start up initially. So it's fetching the blocks, fetching all the transactions for the blocks, and then it's going to index them locally.

All right, so let me switch over to browse. Browser. So, I should have cleared this out beforehand. But I'll just refresh it though so you see I'm actually running query. All right, so I'm just going to run a GQL query, just you know kind of demoing yeah, this is actually a real thing, it's running locally. I'm connecting on port 4000, which you know you can look at the docker-compose and that stuff to figure out more about how we set the ports. But all right, so cool. I ran it, fired it up via docker-compose, didn't do anything extra and look, here we're serving GQL queries. So very easy to get up and running initially and this is the typical experience. If not, hit up our Discord and you can ask more questions there.

And then one other thing I want to show. So here we're showing okay, we're indexing stuff, we're serving out of the index and this is how Arweave applications usually are implemented to query GraphQL to implement a lot of their app logic. Another really important thing though is ArNS, that's that mapping of names to values. So I'm just going to run this. Oh no! Oh, I know what that is. Actually yeah, that's a step in the demo I did not do yet. Okay. So in order to configure that, stop this for a second. It has to know about what hostname we're trying to resolve. Stop this for a second. Okay. So I'm going to copy my .env file here so you see what's in there. It just needs to know this. It needs to know the hostname, like our root hostname, because it can't really look this up in any kind of reasonable way.

All right, now fingers crossed this will work this time. Yep, I think we're good. Tada. Okay, so what is this doing? It's going out and getting the data from Arweave. It's doing that name resolution. By default we're going to sort of delegate the name resolution to arweave.dev, but we actually have a resolver, I just didn't have the guts to live demo it because it's still—that part's still a little experimental—but you can do all that resolution locally based on data that's stored on Arweave, which is really cool.

And yeah, this is kind of like all the—you know, there's a lot of legwork to do still to make all this stuff really robust and solid. Never going to tell people like it's all there. No, it's not. But all the pieces I think are really close to being there, especially now that we have AO and we have I think a smart contracting system that can scale appropriately. Let's see. The only other thing, I think that's pretty much it for the demo, I just wanted to show how easy it is to get started and some of the core things you can do here. There's a lot of other things you can do like run a bundler and submit data. But you can go read our docs and experiment around with that.

I did just want to point this out that we have this ENVs.md, it's in our docs directory, which tells you about all the stuff you can configure. And so if you want to say index bundles, which we don't have turned on by default because you can do it but it's a lot to index, it's a lot of data to pull down if you enable this for everything, but you can configure a filter basically on what you want to index from Arweave. So check this out just to see what kind of knobs we have to turn and things to play with. There's a decent amount there at this point. Okay. So I'm going to stop sharing, go back to my screen and just wrap up the slides. And just for the record, I believe you got up and running after the docker-compose command in like two minutes running a fully-fledged AR.IO node. Yeah, exactly. And that should be what people experience. If you don't, hit us up and we'll try to help you out. That is really how easy it is, no smoke and mirrors there either, that's like doing everything from scratch.

Okay. So features, just going to blow through this real quick and then yeah, that's pretty much it. So I mentioned data caching, we have data caching, we have GraphQL. We have unbundling, which is just processing those bundles, indexing all the data items in them. ArNS, that's the name to value mapping. Again, this thing, like we've tested this, it can basically handle the entire throughput of Arweave right now. You know, with the asterisk of, look, you have to have NVMe drives, it's not a small, trivial system you run this on. But you can do a lot, like I can do hundreds of transactions—transaction-like things, you know, they're not layer-one transactions—but transaction-like things per second on my laptop, which is not like a super high-end laptop. We have a standalone ArNS resolver, so you don't have to rely on anything centralized for that. It is experimental, but you know, all these experimental things are under active development and we're trying to make them very robust as quickly as we can. Integrated bundler, again, experimental. We have optimistic indexing and data just landed. So that means if you're running the bundler right next to your gateway and you're submitting data items to it, they are indexed in your gateway right away. So you can implement things that rely on low latency with this combination, and you don't have to rely on anyone else, which I think is really important. Like back to the open-source thing, I think it's very important that people be able to do all of this themselves. You may use a service for convenience, but you really need an out, you know, because services can go awry, teams can go away. All of this stuff can run independently by you if you need to.

So wrapping up. AR.IO is the gateway network for Arweave that we're building out. Remember: reference by value, not location. Locations at the bottom are just terrible, it causes so many problems. And the infrastructure exists now. It's immature, we have a lot of work to do, but I think really I've been feeling this quite strongly myself. Like, oh, I can build things now. We're close to having what you need to build a lot of really cool stuff. So go out there and build. You'll hit problems, but let us know and we'll try to fix them. And yeah, that's all I have.

Well, man, that was quite informative and yeah, I'm still kind of blown away at how fast it was to get up and running and index live data, which is pretty amazing. Really kudos to you guys for making it super easy for people to get up and running. I guess on the topic of building, what are some interesting applications that you've seen kind of pop up in the last little bit that have caught your eye, or you would recommend people watching this to go explore?

Yeah, there's a lot of really—so there's two things I'm seeing that I think are kind of interesting. You're seeing in AO a lot of sort of porting of core infrastructure from other ecosystems. You know, so you're seeing the DeFi stuff all spring up there. And I think that's, in some ways—I don't want to downplay it—it's like it's copying stuff that needs to be there and it's core infrastructure and that's another part of just having all the primitives we need. So I think that's quite exciting just because we need all that stuff. It's not new in the sense that it's going to be like wildly different on AO. It's going to be similar, it's going to have like slightly different properties because of the different structure of that system, but it's going to be serving a similar purpose. There's also—so there's this like NFT marketplace thing, BazaAR, which was originally using SmartWeave, but SmartWeave had all these issues that made it sort of difficult. That's now on AO. I think that's another really interesting primitive. It's sort of like—I see a lot of these things as kind of like prototypes of what we are ultimately going to have. In the sense that there's just a lot of maturity that needs to come to all these things, right? So they're early. But we're going to have things like that, we're going to have marketplaces for content. And some of the stuff that appears kind of frivolous early on will probably mature into stuff that is a lot less frivolous over time. And if you know, Clayton Christensen, you know, the innovator's dilemma, it's like you often start by carving out these niches that they look kind of weird and like it's—they're carving them out because the big existing players don't want them. You carve them out and then they grow into things that sort of slowly eat into the market share of these more serious things.

So that's the—those are the things I've seen that are sort of most exciting to me. It's like, oh yeah, we're filling in a lot of the gaps here. Things I would like to see a lot more of, which I think would be super cool on AO, is like gaming infrastructure. And I kind of—I kind of don't want it to be funded in some way. Like I just want people to go out and build things they think are fun. I think sometimes the funding really messes with the incentives with games, so they start out like really heavily tokenized and aren't actually fun games. But when I look at this, I see a ecosystem that is close to being good enough to support some really interesting fun games. And if I were not so focused on making it—like making all the infrastructure, I would just build some stuff like that, just play around with it and I hope people do that. Because I think that's another thing—like I think of EVE Online, right? EVE Online is a sort of massive world with this really complex trade economy and all this. We're not going to build something like that out of the gate, but you could build really fun sort of small versions of things like that that I think again would work out a lot of the kinks in these systems and would get us closer and closer to the 'we're going to take over more and more of the internet'. And I think games are a great way to do that because people going into the games, they just realize there—there should be less at stake, right? This is not—it's not like I'm putting my savings into the game economy, hopefully. Please don't do that. So it lets you work out a lot of the issues in these systems if you do things that are like intentionally a little less serious initially. So that's where I would like to see a lot more of that. I think that would be cool, and if I had time I would be messing around with that myself.

Awesome. Yeah. Yeah, I'm still waiting for Web3 gaming to have its moment and I think a lot of the problems that you mentioned before of just like focusing too much on the tokenomics of it all kind of gets in the way and people—yeah, exactly, exactly. Make games fun again. It doesn't have to be like a AAA thing, it can be something as simple as like Flappy Bird or Angry Birds, if you—yeah, exactly. Or even I used to play these text adventure games, you know. Like I think there's a lot of stuff like that you could do that would have some some level of community ownership in the sense that like it can't be taken away from you and people can contribute content, but doesn't need to be this heavily tokenized or like really AAA level graphics, you know. Just make it fun and make it something that people can contribute to and build a community around it. Exactly, exactly. You heard that here first, crowd. Get on it, make gaming fun again in Web3. Yeah, go do it. It'll be awesome. 100%. I guess, seeing as we're pretty much at time, if people are, get stuck or have feedback or need help with something, what's the best way for them to reach out?

Yeah, I think our Discord is best, which actually don't—I can't—go look around. We have links to it I think probably on our our main site and our doc site. Our docs are also quite good, like our getting started docs. Start there, and if those don't answer questions, then go to our Discord. And I'll make sure that there, you know, links to all that stuff, you know, gets to the right channels to end up in show notes. But yeah, I would say getting started in the Discord to help. Excellent. All right. David, it was an absolute pleasure having you on. Really appreciate you taking the time today to show us how easy it is to get started with AR.IO. And hoping to see more folks in the DAO and Web3 in general start to play around with the gateways. Seeing how easy it is, you literally saw it took almost two minutes just from docker-compose to a GraphQL query. So there's nothing—nothing stopping you from getting started today. And as David mentioned, we will have those resources for you available on the description of the YouTube channel. And also if you want to get started with Arweave, remember Developer DAO has worked with the academy team and the AR.IO team to pump out some really great academy courses. So definitely check those out if you haven't already. But with that, before everybody leaves, I would like to share the QR code for you all to scan to claim your NFT for being an attendee here on DevNTell today. So what you want to do is scan this QR code, fill out the form, and you'll be airdropped a DevNTell attendee NFT for being in attendance today live. You'll have an hour and a half from now to be able to fill out this form before it closes, so definitely get on that. But saying that, just want to wish everybody a very happy Friday, a happy weekend, and we'll catch you back here on DevNTell next week. All right, have a good one. Later.