 All right. Next up is me. I'm going to try and go pretty quickly because I would like to see Martin's demo more than I want to see my demo. All right. So let's start. Yeah. Here's what I did. I loaded a file over an IPFS gateway. Right. Cool. We can do this. So that's good. But what makes this different than other loading files over gateways? For those of you who are not fluent in multi-base and multi-formats, this guy over here indicates that we are using a format called BN code or BN code. And what we're doing is loading a BitTorrent info hash. So this is the way in which BitTorrent refers to files. And we were able to load it over a gateway. And in order to do this, so we're sort of doing the IPLD thing. IPLD, data model for interoperable protocols. We would like to have a single way of describing how it is that you build different, how you work with different hash link data structures. So you can sort of work with them together. BitTorrent is a hash link data structure. So we should be able to do that. This is what an info hash looks like. Again, we add support for the codec. Here it is interpreted as DAG JSON. It's got a length, a piece length. They use spaces. God knows why they use spaces. And then this, which is a set of hashes, a set of SHA-1 hashes for various pieces, which are the little file chunks that make up our Koala friend here. In order to do this, so we have the codec, which is this part, which goes in here. But then we also have to say, hey, this isn't a UnixFS file. This is a BitTorrent file. And we did that by passing in a selector, along with our parameter here, an IPLD selector, which you can read more about on the IPLD website. We can use our handy tooling to see what the selector looks like. And here is the selector represented as DAG JSON. It just says, I would like you to please interpret this thing as a BitTorrent file and then match and grab it for me. So that's what we did. Mostly just started by looking at the BitTorrent spec. Here's their encoding format. It's that simple. Here is their data format. It's also pretty simple. Just go and then go implement it in some code. The encoder and decoder just use existing B encoding libraries and the fact that they all kind of turn it to JSON maps. And then just reflect and turn it into IPLD things. The ADL, which is the logic that lets me say this is a, take this graph and represent it as a file, please. Has some boilerplate, but mostly is just sit there and follow the algorithm. How many pieces are there? How big are they? Let me take the keys and break them up into pieces. Then load them for me. All right. A couple of things. So what do we have? We have an ADL plugin and go IPFS that allows us to plug in ADL, like any ADLs. Right now we can only do codecs. Implemented to be encode codec and ADL for BitTorrent files. And this is sort of interesting. A patch for the gateway that will allow for rendering any IPLD node that presents as a file. And that code, it's basically, I run the selector. And if the thing I get out at the end of the day is bytes, you know what, bytes seems like a file. Let's just render it as a file. Maybe slightly controversial to do it the way that was done, but get this moving. All right, cool. So how do you, how do we merge this thing? How do you make this thing actually usable? We need another magic CSV file in addition to the ones we already have to track the names of new ADLs like this one. So people know what they are when they want to go implement them. We need selectors to be implemented in gateways. What I did was sort of a first stab at this, but probably two releases from now and go IPFS, we'll have more of this. We need to plumb custom IPLD link systems through everywhere instead of using the default one so we can handle ADLs. And people need to make sure I did the thing right. I probably read the BitTorrent spec right, but there's BitTorrent v1 and v2, and I may have missed an edge case. So reviews welcome. What do we need to make this like great? Like this seems okay. I can load any BitTorrent file. It means I can also make a BitTorrent client that serves data over both BitSwap and the BitTorrent transfer protocol and basically makes the data available to both networks. And then you can make a little BitTorrent client that makes the data available to both networks. You can make a small BitTorrent client that leaves the client for our profess gateways. But in order make this really great, we wouldn't like to be able to handle transferring large blocks. This is most BitTorrent clients respect the same sort of boundaries that we do, but if they send blocks that are too big, we won't be able to handle them. There's a proposal for that. Also, it would be nice if we could use like Wazem to I don't know who's gonna go implement this thing in JavaScript, but probably won't be me. So maybe just write it once and we can run it in more places. There's actually a Bencode codec in Wasm that I wrote that still works. There's an ADL that is mostly there, but the Panda, the Koala renders a little funny at the moment. So I started programming Rust on Sunday. So anyone who knows any Rust, help appreciate it. And thank you. More demos later. Cool. Next up.