 Hey, I'm David, Lead for DAG House. We build web three storage and energy storage, which have grown a bunch in the last year. Alan, might flip to the next slide because it is a reliable performance, hosted IPFS solution that gets your data onto Filecoin. You can see total uploads have grown to 80% over the last year, but today's deep dive is about our next chapter as a team and a product. Next slide, please. To meet the needs of our users, we've had to utilize centralized and per providers for performance, reliability and scalability reasons, but the plan has always been to increasingly rely on decentralized Filecoin as it's become ready to reduce costs and take advantage of the global network of many independent nodes. Next slide. We had been planning to nucleate this year with the immediate focus for us on adoption with users willing to pay a premium for our services, but given crypto winter, we've pivoted now to helping Andres enable the end-to-end Filecoin story from a user's perspective. This includes building protocols in libraries for developers to take advantage of Filecoin, regardless of whether or not they're a Web3 or NFT storage user and dog-fooding these protocols ourselves to progressively decentralize our own infrastructure as the Filecoin stack becomes increasingly mature. Next slide. So, W3UP, we're excited to share details of our new upload protocol, W3UP, in today's deep dive and continuing throughout March. You might have heard a little bit about this in Lisbon last year and it's come a long way since. W3UP is a storage protocol, API and set of clients that allows users to verifiably upload data using their own identity. It's designed as a protocol to be used by any quote-unquote storage service, not just Web3 and NFT storage, but anyone moving data around, especially across permission boundaries. We think it could be really useful for many Andres and PLN projects. W3UP offers a layer of abstraction for an actor to send data to another actor, only it does so in a self-sovere and verifiable way, bringing IPFS and decentralized authorization protocols to the table. It fills a similar need, quote-unquote, S3 compatibility compliance is trying to fill, only it's truly portable top to bottom. This also allows us to progressively decentralized our services as decentralized info options become viable to fully rely on without requiring a big code migration from our users' perspectives. But it also does have a number of immediate benefits as well, such as faster uploads. Next slide. And here's some of the libraries we've been working on from the W3UP spec to the protocol and reference implementations to the libraries built on top, like headless front-end components and a CLI. Next slide. And we're in beta and users like OpenSea, TableLand and Koi have been trying it out and have had positive feedback about its interface and simplicity and how it just works. And then we have an RC coming out in a few weeks. Next slide. And then in building W3UP, we've incorporated our teams' learnings from running our hosted IPFS services at scale with competitive performance reliability and talking to a bunch of users. These learnings are most obvious in two categories of lower level protocols. I know the word protocols is used generally pretty loosely, but we're heavily relying on what we call together the deep space nine protocols, these lower level protocols. Next slide. And these two categories, so first for data verifiability, we obviously use IPFS, but more specifically when we can, we send around sets of blocks and car files and verify those rather than transacting block by block. And this is even the case in user-facing situations like uploads and reads. And then for auth, we use UCan. We've worked a bunch with Fission to design a protocol that services can practically use. I'll roughly share this work in the UCan and invocation spotlight earlier. And aside from user-owned identity and the benefits that come with that, UCan also notably allows permissions to be trustlessly delegated from one party to another. Next slide. And then hopefully efficiency with verifiability sounds great to you. And taking a step back, we think there's a lot of others in the PLMN, a lot that others can utilize from W3UP and DS9, especially because they were built to be generic protocols. And our goal today is to get you excited enough in them to explore more. And in terms of folks to get you excited, no better person Alan Shaw, so I'll hand things off to him to talk more about the technical bits. Oh, no. Okay, David, thank you. I'm going to deep dive in five minutes, but this is going to be a little deep dive on the new architecture we have for web-free storage and NFT storage. And we call it W3UP and here it is. So here is the big architecture diagram, but don't worry, we're going to build it really slowly. So it's easier to understand. So first of all, client-side, server-side, you understand that sort of stuff. But yeah, we have the client, and it could be like the CLI or the client libraries or a web app, but what it does is it does some work locally. And that's on the left-hand side there. And what it does is it creates a car file of some DAG of their upload or the thing they want to upload. And this is done in like a streaming manner. And this is interesting because like all of our DAG generation tooling in JS so far has been focused on putting blocks in a block store. So then we have to create the DAG in memory or on disk and into a block store and then export it. And this is just like a slow and kind of memory intensive and disk or disk space and intensive, depending on how you do it. And like in browsers, you only get a certain amount of memory to be able to do that sort of thing. You don't want to have another copy of it in memory. So we've had people complaining about that. So we built these tools to make it easier to just stream stuff up to our service. So that's kind of cool. And so the other thing that the client does is it signs a UCAN with like details that are specific to their upload and it invokes this storage method, which is store slash add. And it's either for their account or for someone else's account where they've been delegated access to put stuff in it on behalf of them, which is amazing. FYI, UCAN stands, if you didn't know, stands for User-Controlled Authorization Network. And so we've been collaborating with Fishin on the spec. And UCANs are essentially an extension to JWTs and they allow users to authorize what they do themselves. It's amazing. So anyway, once the UCAN is signed, it gets sent to our W3UP API. And we call this a UCAN invocation. And the server validates the signatures on a delegation chain in the UCAN. And that ensures that the user has sufficient access to invoke the action or what it's called in UCAN terms is capability. And so in this case, the user is asking to add a car file to their storage space. And so what we do is when we send car files, we actually address them by a CID. And that CID is a car CID. A car CID is just a special CID that is the hash of the entire car file. And that hash is baked into a signed URL that is sent back to the user. And then that URL ensures that the data they upload must hash to the same value as the car CID. So that's super cool. And then the user takes that URL and uploads the data to that URL, the data being the car file. And then the upload is complete. So that's super rad. And the difference here from our old infra is aside from the UCANs, which is like huge anyway, but the car goes directly into a bucket. So there's no proxying for your worker. They don't send it to us. They send it directly to where it needs to be. And that is effectively a speed increase and a cost reduction. And perhaps most importantly, the upload location doesn't necessarily have to be our service. It could go straight into Saturn or Filecoin, for example. So that's super cool. So then when the upload is in Alastair KaviFS, it's available for BitSwap availability, for other people to BitSwap as they do. I've talked a bunch of times about how Elastic works. So I'm not gonna repeat it here. I did a really good talk, I think I did a really good talk at IDFS camp called Five Billion Blocks. If you're interested in Alastair KaviFS and how it works, then check out that. So anyway, this upload process, it's much faster and more reliable than it was previously because the cars are generated in the streaming manner rather than all in memory. And also by storing it directly into the bucket, our per upload request chunk size can be like four gig. It doesn't have to be like a hundred megabytes anymore. And then this is just makes stuff a whole lot faster. So it's super cool. Then you can see the difference in these benchmarks where for W free up, you can see like around 40% or faster upload speeds. And then we can do some more optimization to make this faster. The second upload is the same data. And the cool thing about W free up is because we're using car CIDs and addressing things and using content addressing properly, you effectively get infinite compression. You don't have to upload the thing. Again, if someone else has uploaded that car file, the service just says you're done and you don't have to upload it. So it doesn't take any time to upload the thing. It's a hundred percent speed increase from. Anyway, you get the idea. Okay, so anyway, back to the diagram. Sorry, moving on and on with a short on time. The car is also sent to our Cloudflare-hosted HTTP gateway. It's cashed there for fast availability over HTTP. Our gateway is called W free link. You can access it at W free S.link. It's kind of similar to D web.link. And so the data gets copied there and it remains as a car at rest. It means that our gateway serves data, serves IPFS content address data directly from car files, which is kind of cool. And in our gateway, we build some awesome indexes. We call one of them dudeware. The other one is called sat nav. And that allows us to serve the IPFS content address data directly from those car files. Dudeware tells you which car files your DAG can be found in. It's a mapping from root CID of the DAG to one or more car CIDs. And then sat nav is navigation within your car. Sat nav index is a mapping from car CID to all the block offsets within the car file. So it's actually a car V2 index if you know and care about that sort of thing. Anyway, I digress a little bit. So if you want to know a bit more about gateways then check out our gateway. It's called Freeway. It's very fast and good fun. Anyway, so pretty soon Spade will be helping us put those car files in Filecoin deals with boost storage providers and renewing them as well. So that's gonna be awesome very, very soon. And then throughout this whole process, our verifiable UCan log store collects these UCANs that we add and that will later provide us with verifiable transaction receipts. And we can also track metrics through the data pipeline by looking at these UCAN logs that we've got. So you can also see the benefits of using UCANs with user owned identity in a new architecture. There's verifiability at every step in permissioned interactions and user owned portable identity. Delegatable permissions allow more efficient data pipelines from when the data is sitting. So for instance, like if you're a NFT minting tool you can have your users upload directly to W3UP without needing to run a server to proxy the upload. And they don't even need to know that they're uploading to W3UP because they can just be delegated the permission to do it and then just send their data where it needs to be. So they don't have to register with us or anything. They just, they can just be given access which is rare. Cool. I'm probably need to skip this. I'm gonna skip this bit. The, I'm gonna quickly just talk about the problem that this is solving. And then if you wanna look at the slides afterwards I can, the biggest UX problem we have is how to make like public key cryptography tenable to a Web2 crowd. Web2 crowd are like, they used to centralize services and just let you log in with your address. And so the problem is when you switch devices or lose a device or drop your phone in the toilet then how do you gain access to your stuff? If you lose your private key or don't have access to it from another device? Well, we have a solution for that. And that allows you to gain access to your stuff using just your email. And these are the slides that I'm just gonna breathe past because I don't have enough time to present them but you can go and look at them. Anyway, blah, blah, blah, blah, blah, there we go. Cool. All right. So wrapping up hopefully up next for W3UP is that we've built this UCAN based auth protocol so we can run W3UP on decentralized infra as well. DAG house, we're doing this a lot with our products but based on your user's needs you can use W3UP whenever you need to and get the UX benefits that provide. So, but some of the, my favorite ideas that we're hopefully gonna try and get to doing is writing up those directly to SaturnL1s or Fargo NSPs and UCAN validation and receipts and on the chain using the FEM would be super rad. So I'm really excited for some of this stuff that is just literally opening up for us to take advantage of. Very cool. All right, that's about enough from me and David, I'm really sorry it's taken so long but if you're interested in this then please reach out. You can check out our current beta. It's out in a moment. We're hoping for an RC later this month. Yeah, oh demos, we got two demos, demo sessions, a big demo session for deeper dives if you're interested in actual demo and usage and how things work on the March 24th. WAP on the 31st and we'll record it and you can have it. And yeah, thanks for letting me squirt my voice at you for a while.