WEBVTT 00:00.000 --> 00:11.000 Okay, we're on time. I'm feeling amazing. 00:11.000 --> 00:15.000 I've got to introduce Robin, who is going to dazzle us in all possible ways. 00:15.000 --> 00:21.000 There might be some ways that I don't dazzle you in. 00:21.000 --> 00:23.000 Let's just keep. 00:23.000 --> 00:25.000 Hi, everyone. Thank you for coming. 00:25.000 --> 00:27.000 It's a pleasure being here. 00:27.000 --> 00:33.000 I'm going to introduce dazzle, which is essentially a toolbox to build other things with. 00:33.000 --> 00:41.000 So it's a little bit complicated to make an interesting presentation about this because it's like pretty low level and low level and low level. 00:41.000 --> 00:45.000 But you know, let's try to at least make it bright. 00:45.000 --> 00:50.000 And so this talk is pretty good if you like bright colors because you know, 00:50.000 --> 00:55.000 and it tended to focus on, you know, brightening it up, brightening it up. 00:55.000 --> 00:59.000 If you like acronyms, there's going to be a bunch of acronyms. 00:59.000 --> 01:02.000 And they all mean something or almost all of them. 01:02.000 --> 01:05.000 But also, like if you're interested in kind of addressing, you haven't used it. 01:05.000 --> 01:08.000 Or you tried using it and it really, really sucked. 01:08.000 --> 01:19.000 This is a good place to get started to get either acquainted or reacquainted with kind of addressing and how you can use it in different contexts. 01:20.000 --> 01:23.000 And so what is content addressing? 01:23.000 --> 01:32.000 I assume everyone in this room knows what it is, but just on the off-chance that you haven't like looked it up recently or it's not something that you've used is pretty straightforward. 01:32.000 --> 01:42.000 You have a resource of any kind and you get typically it's a hash, but like some kind of unique representation derived from the content itself. 01:42.000 --> 01:47.000 And then you have that unique representation and you can get the content back. 01:47.000 --> 01:57.000 That's basically what it is. There's all kinds of variations about it. There's all kinds of different ways of doing it, but the fundamental is basically this. 01:57.000 --> 02:01.000 It's a very simple idea, but we can do a lot with it. 02:01.000 --> 02:08.000 But before I jump in, I want to address the fact that dazzle is part of the IPFS suite of things. 02:08.000 --> 02:11.000 We don't have a good name for the IPFS universe. 02:11.000 --> 02:21.000 When you start by calling your thing into planetary something something then it becomes like this big thing and you know what is it like a Federation of planets or something like that. 02:21.000 --> 02:27.000 But that's all is basically in that universe galaxy, whatever you want to call it family, big happy family. 02:27.000 --> 02:35.000 And so if you think of IPFS, you can think of it as like a very very big system, I mean very big system. 02:35.000 --> 02:45.000 There's a lot going on in IPFS and it's very file system oriented as the name might have, you know, like revealed to you initially. 02:45.000 --> 02:57.000 And it does a lot, you know, the IPFS family of things has like live PTP, has a distributed hash table, there's a public network called amino. 02:57.000 --> 03:02.000 And essentially there's a lot of implementations and they do a lot of stuff. 03:02.000 --> 03:12.000 But as always a part of that, but it's really intended to focus on something that allows you to build your own protocol, your little system. 03:12.000 --> 03:21.000 Essentially, if you don't want to start with like something that already has a DHT already has like a PTP layer already has a lot of stuff built in. 03:21.000 --> 03:31.000 But you basically want to compose your own system and you want to do it in a way that is easily easy to make compatible with web environments either because it's relatively light. 03:31.000 --> 03:43.000 Or because it has primitives that are very web oriented, I just noticed that that clock is dead, I shouldn't trust it. 03:43.000 --> 03:54.000 It once happened to me that I timed, you know, put a timer on my presentation, but instead of making it 25 minutes, I made it 45 hours. 03:54.000 --> 04:00.000 And I was like, ah, talking and talking, oh, shit, it's still 44 minutes left, I'm going way too fast. 04:00.000 --> 04:03.000 It took me like, you know, a while to anyway. 04:03.000 --> 04:05.000 That's not to that today. 04:05.000 --> 04:12.000 And so the idea with dazzle is really that less sometimes can be more, so it does a lot less than the full IPFS stack. 04:12.000 --> 04:15.000 It has far fewer options, but the idea is that you can just get it off the shelf. 04:15.000 --> 04:20.000 And the philosophy behind that is just to take a few very basic principles. 04:20.000 --> 04:29.000 So first we want to pave the cow past, which is to say, if someone's already using the tech in a way that's, you know, that works. 04:29.000 --> 04:42.000 Even if we don't like it, even if it's not my, you know, favorite shade of, you know, pink or orange or whatever you want, we're still going to use it because adoption matters more than whatever my personal opinions are. 04:42.000 --> 04:48.000 We focus on extensibility more than on optionality that might sound a little bit abstract. 04:48.000 --> 04:55.000 But like if you look at CIDs, the identifiers used used in IPFS, they have a lot of options. 04:55.000 --> 05:02.000 And that's good because it means if you need change over time, you can change how your identifiers are generated. 05:02.000 --> 05:10.000 However, because everyone uses different options, or it's very easy for many people to use different options, people generate different identifiers. 05:10.000 --> 05:18.000 And when you have different identifiers in a content address system, you don't find one another because you don't have the same ideas. 05:18.000 --> 05:33.000 And so in dazzle, we keep the extensibility, like when things change, or when there's a very specific, you need that that rises, we, you know, have the ability to generate different kinds of identifiers that meet that need better, for instance. 05:33.000 --> 05:37.000 But like we don't encourage optionality, most things have zero options. 05:37.000 --> 05:42.000 They're just like have very, very, very set options, and we'll look at that in detail afterwards. 05:42.000 --> 05:48.000 There's also a thing that's like, it's don't make me think, get the library it just works. 05:48.000 --> 05:57.000 It's like, in fact, if you could start using kind of the dressing without even remembering that you're using kind of the dressing in our mind, that's really a win. 05:57.000 --> 06:14.000 There's been difficulty, you know, like, if you look at the, a lot of the decentralized stacks, I've heard from many people things like, oh yeah, I really wanted to use that kind of like decentralized system for my startup, but I used my entire runway getting that to work without ever building a product. 06:14.000 --> 06:18.000 And this is what this is really what we're trying to avoid. 06:18.000 --> 06:30.000 It needs to be lightweight. Again, you find a lot of these systems that have, like, really nice properties, and then you want to use them in a browser and it's like a five gigabyte wasm file to get started. 06:30.000 --> 06:36.000 Those are like, not great. This, they should work like, you know, out of the box in your browser as much as possible. 06:36.000 --> 06:44.000 And it really is a unique philosophy. If you've ever looked at specifications or standards out there, and I've been guilty of a few of those. 06:44.000 --> 06:51.000 It was the editor on the WC side of the HTML5 standard, which is something like 1200 pages. 06:51.000 --> 06:58.000 Most of these are like, you know, one three-page standards specs. They're very, they're very simple. 06:58.000 --> 07:03.000 And they meant to be like extremely basic functionality that composes well. That's how we approach it. 07:04.000 --> 07:13.000 But, you know, enough of this introduction, here's like a few of the core specifications. So they're three core specs. 07:13.000 --> 07:20.000 And when I say they're simple, they're really, really simple. The goal is really that it's toolbox and that you don't have to think about it. 07:20.000 --> 07:25.000 So, consider the identifiers. Well, I mean, how many different ways can there be to encode a hash? 07:25.000 --> 07:31.000 It turns out that it can be quite a few ways if you do it, like, you know, in a very open-ended way. 07:31.000 --> 07:42.000 But this is essentially a way of having a hash with a tiny bit of metadata that makes that makes the identifier extensible so that we can, like, have variants. 07:42.000 --> 07:50.000 But really, if you go to dazzling dots, the, hey, don't you love this serial hack. Anyway, dazzling slash the ID dot HTML. 07:50.000 --> 07:57.000 You can see that a CID is, like, is very basically thing. It's always based 32 encoded. It's always v1. 07:58.000 --> 08:04.000 It's at there, there are only two codecs. This is to point the Royce to point at, like, a resource like an image. 08:04.000 --> 08:09.000 The structured data is to point at structured data, which we'll see on the next slide. 08:09.000 --> 08:14.000 And the hash is always, um, a shaft I've 12 and it's always the same length. 08:14.000 --> 08:20.000 The reason these options exist is because in the IPvs world, all of them can have different settings. 08:20.000 --> 08:25.000 And so you can have, like, all kinds of ways of generating identifiers. 08:25.000 --> 08:32.000 And in fact, in dazzle, there's one case in which we actually use a different hash type in one situation as an extension. 08:32.000 --> 08:42.000 But 99.9% of the time, this is what you're going to get. So you don't need to think about it. You can just get a really simple identifier. 08:42.000 --> 08:50.000 And one of the things that's really useful in the content addressing system is deterministic data structures. 08:50.000 --> 08:55.000 And so this is inherited from, if you're familiar with it, from the IPLD world. 08:55.000 --> 09:02.000 And we have something called drizzle. And drizzle is essentially a deterministic variant of seabore. 09:02.000 --> 09:07.000 Seabore is, you know, yeah, basically think of it as Jason, but it's, it's deterministic. 09:07.000 --> 09:19.000 When you encoded, you only get one, one, for any given abstract, um, a set of data sets, you will only get one byte stream coming out that's always the same. 09:19.000 --> 09:28.000 And so it's a version of, uh, of seabore that supports CIDs, so the previous thing as a native type, so that you can have links between things. 09:28.000 --> 09:36.000 And so one of the values that you can have in your drizzle document is a CID that points to another drizzle document or to a resource. 09:36.000 --> 09:43.000 And so that means that you can have a system that natively, even without understanding the semantics of what you're encoding, 09:43.000 --> 09:48.000 can navigate the entire graph and find all kinds of other resources. 09:48.000 --> 09:58.000 And so this has been, um, also, uh, filed as an internet draft with the ITF known as the tag 42 profile of seabore core. 09:58.000 --> 10:03.000 It's like tag 42 is, is the, is the specific seabore tag for CIDs. 10:03.000 --> 10:13.000 It's been registered a long time ago, um, and that defines drizzle and, um, and CIDs, uh, on the ITF side of the world. 10:14.000 --> 10:22.000 A third core and the, that's like really the core of, of this stuff is like three tiny specs is called car. 10:22.000 --> 10:30.000 Um, car is basically a very, very, very basic way of putting a bunch of content address resources into one single package. 10:30.000 --> 10:36.000 So if, if you know, if you've ever looked at how tar works as a format, you can make tables with it. 10:36.000 --> 10:48.000 Well, with car, you can make car balls. And it's, essentially, it's very simple. It's, um, every single entry in a car ball is prefixed with a, the CID of that chunk. 10:48.000 --> 10:54.000 So that you know that you're getting the correct thing, um, and it's, and, and the length of the, of the content. 10:54.000 --> 10:59.000 So basically you can simply like, like, skip, skip, seek and like verify on the fly. 10:59.000 --> 11:07.000 One thing that's very important is the reason the CID is included is because the CID means you can always verify the content, right? 11:07.000 --> 11:12.000 That's always, that's a key property of content address systems is that you can get the content from anywhere. 11:12.000 --> 11:20.000 And you can always know that you're getting the right content because it matches the hash of the identifier that, that, that, that, that you got to get it with. 11:20.000 --> 11:23.000 So I'm not going to list all the specs in one go. 11:23.000 --> 11:31.000 I'm going to take a small break between listing all the specs to show, um, to talk about, like, a few real world examples that use these three core specs. 11:31.000 --> 11:42.000 And the biggest, like, the widest, the deployment, um, of, of, of, of dazzle is 80% of 80% of natively uses dazzle under the hood. 11:42.000 --> 11:51.000 Um, anything you write to a PDS, uh, anything that you get on the relay, if it's not there, the, the, the adjacent, if it's not the jet stream relay, um, is drizzle. 11:51.000 --> 11:53.000 So it's all drizzle drizzle drizzle. 11:53.000 --> 11:59.000 All the blobs, everything that you, that get stored on there is, uh, a, a storeless CIDs. 11:59.000 --> 12:01.000 And everything exports as car. 12:01.000 --> 12:04.000 And when I say 80% of this is not something that's a Bruce guy only. 12:04.000 --> 12:09.000 This is like the, the, the heart, you know, completely part of the protocol. 12:09.000 --> 12:15.000 So I just listed a few random things, you know, black sky, um, leaflet flashed, uh, tangles senseo. 12:15.000 --> 12:18.000 Like, these are like completely different applications. 12:18.000 --> 12:21.000 They all use dazzle under the hood directly. 12:21.000 --> 12:26.000 On top of that, of course, this is also used in a number of IPFS projects. 12:26.000 --> 12:33.000 So, you know, everything that's dazzle compliant, uh, you can just, like, put it on Amino and it will just work. 12:33.000 --> 12:35.000 Kubo supports it out of the box. 12:35.000 --> 12:41.000 Next, an excellent work on CID profiles that help integrate dazzle, uh, even more easily in there. 12:41.000 --> 12:43.000 And it's work with Iro protocols. 12:43.000 --> 12:49.000 If you're familiar with the Iro library and set of tools that does that streamplace is in the house. 12:49.000 --> 12:54.000 Also uses dazzle, um, and we're going to talk more about streamplace afterwards. 12:54.000 --> 13:01.000 And so all of this is is is, you know, it's pretty, it's pretty, it's used at pretty real scales. 13:01.000 --> 13:03.000 And there's a whole bunch of implementations. 13:03.000 --> 13:05.000 And not can name check all of them. 13:05.000 --> 13:11.000 If you go to dazzling, uh, to dazzle.ing, those are listed with links and, and more descriptions. 13:11.000 --> 13:17.000 But this is to say that, you know, this is properly implemented with a test suite. 13:17.000 --> 13:23.000 Um, that, that shows like, uh, imperfect, but very decent levels of interrupt. 13:23.000 --> 13:29.000 And that, that interrupt keeps growing, um, very, uh, pretty impressively fast. 13:29.000 --> 13:35.000 And so on top of that, because we made these like tiny specs that do the thing and that work, 13:35.000 --> 13:37.000 there's some more advanced. 13:37.000 --> 13:41.000 And when I say more advanced, they're really not very advanced. 13:41.000 --> 13:43.000 Because everything's like a small tool. 13:43.000 --> 13:45.000 But like they're more specialized. 13:45.000 --> 13:49.000 You might think of them as like, uh, less, less widely used in CIDs, 13:49.000 --> 13:51.000 but like more, more applied to specific cases. 13:51.000 --> 13:57.000 And so for instance, Razle, because you want to Razle your dazzle, um, 13:57.000 --> 14:03.000 is a retrieval spec for to get like CIDs, um, over, um, HTTP. 14:03.000 --> 14:07.000 And the idea being like, yeah, if you're in the IPS world, 14:07.000 --> 14:11.000 if you're familiar with that, the typical case, you don't have to do it that way, 14:11.000 --> 14:13.000 but the typical case is you have a CID, 14:13.000 --> 14:17.000 and you hit the public DHT, and you find someone who's, who's, who's publishing it, 14:17.000 --> 14:19.000 and you get it from them. 14:19.000 --> 14:25.000 We don't have that because there's no DHT, there's, there's no peer-to-peer layer in, in dazzle. 14:25.000 --> 14:31.000 And so the idea with Razle is that you can have a link that basically has the CID, 14:31.000 --> 14:35.000 as it's authority because that's what you're getting. 14:35.000 --> 14:39.000 If you know where to get a CID, if you already have it, or there's any kind of retrieval method, 14:39.000 --> 14:41.000 you want to use. 14:41.000 --> 14:42.000 You'll find using that. 14:42.000 --> 14:45.000 That's one of the things that's really powerful with content addressing 14:45.000 --> 14:48.000 is it really doesn't matter where you get the data from. 14:48.000 --> 14:51.000 So any implementation is free to like, optimize things away 14:51.000 --> 14:54.000 and decide how it wants to, to find things. 14:54.000 --> 14:57.000 However, if you don't know where to get that CID, 14:57.000 --> 15:03.000 the link can include hints, and those hints will be HTTP endpoints 15:03.000 --> 15:08.000 that are supposedly able to provide exactly that CID. 15:08.000 --> 15:13.000 And the way you do it is that you just go to hdps hint slash dot well known, 15:13.000 --> 15:15.000 slash Razle slash the CID. 15:15.000 --> 15:20.000 And normally if the URL isn't lying about the hint, 15:21.000 --> 15:24.000 working, you're able to retrieve it from that. 15:24.000 --> 15:26.000 Again, this is a very simple spec. 15:26.000 --> 15:29.000 You can, you know, it's a two-page thing. 15:29.000 --> 15:34.000 There's, there's, there's an implementation of this for express. 15:34.000 --> 15:36.000 I believe there's an implementation of this, 15:36.000 --> 15:39.000 and I should get what other language for something else. 15:39.000 --> 15:42.000 But like, this is a basic way of like exchanging data 15:42.000 --> 15:43.000 and content address ways. 15:43.000 --> 15:47.000 The idea is that this can be a brick with which you can build 15:47.000 --> 15:50.000 very easy data sharing arrangements. 15:50.000 --> 15:55.000 So that, for instance, maybe D trick and Dom and Marsh, 15:55.000 --> 15:57.000 all want to have like, they make a little community, 15:57.000 --> 16:00.000 and they want to pull their, their blogs or whatever. 16:00.000 --> 16:04.000 They can all republish one another's data very easily 16:04.000 --> 16:07.000 using this kind of system by syncing with one another 16:07.000 --> 16:09.000 and then making it available. 16:09.000 --> 16:13.000 You don't need like a complicated setup to to make that work. 16:14.000 --> 16:17.000 Another chunk that's, that's interesting. 16:17.000 --> 16:21.000 If people are standing by the door, this, this seats if you want. 16:21.000 --> 16:23.000 Don't worry about it. 16:23.000 --> 16:26.000 And so, another thing that's, that's interesting is so, 16:26.000 --> 16:31.000 Mazel is the metadata spec for bundles of, of dazzle data. 16:31.000 --> 16:36.000 And the idea here is that it's essentially like a web manifest. 16:36.000 --> 16:40.000 It's drizzle encoded, of course, but it's essentially like a web manifest. 16:40.000 --> 16:46.000 And the idea is that you can find resources by mapping that, 16:46.000 --> 16:50.000 that this path to a CID in the metadata. 16:50.000 --> 16:53.000 So this kind of look up, makes it, please, please, please, please, 16:53.000 --> 16:56.000 makes it really easy to like have something that's web like. 16:56.000 --> 17:00.000 So you have like an index.html and it's pointing to some images 17:00.000 --> 17:02.000 and some JavaScript to some style, whatever. 17:02.000 --> 17:07.000 And you put all of this in like, a big manifest like that. 17:07.000 --> 17:10.000 And well, not that big into a manifest like that. 17:10.000 --> 17:14.000 And you put them all like, in a car or something like that. 17:14.000 --> 17:19.000 And you have the basically a self-contained little web thing that works well. 17:19.000 --> 17:24.000 And this is sort of an iteration on the work that had been done over IPFS. 17:24.000 --> 17:29.000 But like the idea of like having the full path encoded here means that you don't have 17:29.000 --> 17:34.000 to like map it back to a file system and hope that the file system maps back to, 17:34.000 --> 17:36.000 to HTTP ideas. 17:36.000 --> 17:39.000 And also one thing that's, that's particularly important. 17:39.000 --> 17:46.000 And one of the reasons why Mazel is very useful for web like web app like use 17:46.000 --> 17:50.000 cases over content address systems is that the idea really with content 17:50.000 --> 17:53.000 addressing is that again, you can get data from anywhere. 17:53.000 --> 17:55.000 You can get the source from anywhere. 17:55.000 --> 17:59.000 And you don't have to trust it because you can always verify that you're getting the right thing. 18:00.000 --> 18:07.000 However, web content is meaningful in the context of the headers that deliver the resource. 18:07.000 --> 18:14.000 And if you change the headers of a given resource, you might change its interpretation depending on which headers you changed. 18:14.000 --> 18:23.000 Therefore, if you're getting just the body of response and you're getting it through a gateway or something like that that sets headers for you. 18:23.000 --> 18:27.000 That guesses them or that just like comes up with random stuff. 18:28.000 --> 18:35.000 Then you might find yourself with security issues or you might find yourself having interrupt issues. 18:35.000 --> 18:42.000 And therefore, what Mazel does is it makes those headers portable and attached to the resources so that you can just like distribute them around. 18:42.000 --> 18:51.000 And you get the full basically HTTP envelope with the body included so that you can get something that's actually safe and interoperable. 18:51.000 --> 18:54.000 And a third more advanced thing. 18:54.000 --> 18:56.000 This one gets a little bit more complicated. 18:56.000 --> 18:59.000 There's something called Bedazzle. 18:59.000 --> 19:02.000 And I insist that you say it that way. 19:02.000 --> 19:05.000 It's called Bedazzle for Big Dazzle. 19:05.000 --> 19:11.000 And the idea is that instead of using Shopify 12, we use Blake 3 in this case. 19:11.000 --> 19:13.000 So this actually uses different CIDs. 19:13.000 --> 19:16.000 It uses a different option in the CIDs. 19:16.000 --> 19:22.000 In a perfect world, we would have used Blake 3 for everything from day one, I think. 19:22.000 --> 19:28.000 However, the paved the cow path idea meant that that was not compatible with the roof stuff. 19:28.000 --> 19:33.000 And Blake 3 is still not supported in browsers so that that also creates problems. 19:33.000 --> 19:37.000 So like this compromise meant that we use it this way. 19:37.000 --> 19:46.000 But one thing that I'm particularly excited about is that with Blake 3 support, not only can we like deal with like large, large, large, 19:46.000 --> 19:48.000 large, large, large, large, large. 19:48.000 --> 19:51.000 But we can do streaming verification. 19:51.000 --> 19:52.000 And I'll get to that. 19:52.000 --> 19:56.000 It's something that we shipped, I think, what the 10 days ago. 19:56.000 --> 20:00.000 10 days ago ish in Bedazzle. 20:00.000 --> 20:04.000 It's the ability to stream verify verification. 20:04.000 --> 20:09.000 And to do verification on chunks of range requests. 20:09.000 --> 20:12.000 I'll get to that on the next slide. 20:12.000 --> 20:15.000 Because it's also about future things. 20:15.000 --> 20:25.000 So as I said, we have shipped Bedazzle support with Blake 3 and with a description of how you can do streaming verification. 20:25.000 --> 20:28.000 But the system isn't completely finished in that. 20:28.000 --> 20:34.000 Some of the bricks that I required to make it work are not completely specified yet. 20:34.000 --> 20:38.000 The big value that you get here is like two primary use cases. 20:38.000 --> 20:40.000 One streaming huge things. 20:40.000 --> 20:47.000 So with content addressing, one of the problems is in order to verify that you got the right thing, you need the whole thing. 20:47.000 --> 20:52.000 So say I'm streaming like a 20 gigabyte video to you. 20:52.000 --> 20:58.000 You know, it lies maybe it's like 60 hours long and you like spent those 60 hours watching the video, etc. 20:58.000 --> 20:59.000 Yeah, the other. 20:59.000 --> 21:00.000 And it gets to the end. 21:00.000 --> 21:02.000 And she actually got the wrong video. 21:02.000 --> 21:04.000 And so it doesn't verify. 21:04.000 --> 21:07.000 Now now I'm like, you spent the last 16 hours watching something. 21:07.000 --> 21:09.000 You don't even know if it's the real thing. 21:09.000 --> 21:11.000 What might have been hacked or whatever, right? 21:11.000 --> 21:13.000 That's not great. 21:13.000 --> 21:18.000 And so the idea with Blake 3 is that you can support streaming verification. 21:18.000 --> 21:26.000 We've specified how our Blake 3CIDs map to the streaming protocol in Blake 3. 21:26.000 --> 21:30.000 One thing that we're still missing is the sidecar. 21:30.000 --> 21:36.000 We sort of like need a little sidecar that can give you a, basically, a miracle tree of hashes. 21:36.000 --> 21:37.000 Everything's a miracle tree. 21:37.000 --> 21:39.000 These days I love it. 21:39.000 --> 21:42.000 And so there's this, there's this, there's the original thing called bow. 21:42.000 --> 21:45.000 There's a, there's a more general thing called Bab. 21:45.000 --> 21:51.000 It's likely that we're going to like sort of like mash up the two, two, two, two, two, do a bow Bab. 21:51.000 --> 21:59.000 And, and another thing that I'm really excited about here and that the folks at computer zero have already implemented, 21:59.000 --> 22:04.000 at least some of that in, in, in, in Iro is not just like streaming verification, 22:04.000 --> 22:06.000 but range requests verification. 22:06.000 --> 22:12.000 And so let's assume you have like a petabyte scale, you know, duck DB database, 22:12.000 --> 22:18.000 somewhere on any kind of like HTTP server that supports range requests. 22:18.000 --> 22:25.000 You can just like, you know, make a range request forward like the headers that give you the tell you how to find stuff. 22:25.000 --> 22:32.000 And then you can just, when you make a query query by like doing range requests against that without loading the whole thing, 22:32.000 --> 22:38.000 but while still verifying cryptographically that you're getting the real data whenever you make range requests. 22:38.000 --> 22:46.000 And that's something that's that that I find like very powerful, powerful feature that I'm really excited to see happen in that space. 22:46.000 --> 22:49.000 Another thing I promised you like more stream play stream plays. 22:50.000 --> 22:57.000 Yeah, I promised you more stream play stuff or collaborating with our friends at stream place on something called stupa, 22:57.000 --> 23:05.000 because again, we need, we need more accident acronyms and I have say that one that one is good. 23:05.000 --> 23:11.000 What's the other one that we had like, oh, muxel tree because like it's a miracle tree of muxels. 23:12.000 --> 23:18.000 And so the idea here is essentially to work on two things, those specs don't exist yet. 23:18.000 --> 23:21.000 We're going to work on them pretty soon. 23:21.000 --> 23:26.000 I mean, like the work has started, like you're going to start seeing some work soon. 23:26.000 --> 23:32.000 One is you need deterministic MP4 containers because once you start putting stuff inside MP4 containers, 23:32.000 --> 23:39.000 it turns out that the spec isn't very deterministic and it actually like tends to require things that are not deterministic at all. 23:39.000 --> 23:43.000 So in order to be able to reproduce things, we need a specific way of looking at that. 23:43.000 --> 23:49.000 And the other thing is sort of like a, can we call it a rent free c2pa. 23:49.000 --> 24:00.000 Essentially, it's a subset of c2pa that doesn't require like buying into the novel certificate authority kind of kind of thing. 24:00.000 --> 24:07.000 And so the idea being that you can like have like a chain of custody, a full video data with that. 24:07.000 --> 24:14.000 And third one that's also also coming is web tiles and web tiles is that. 24:14.000 --> 24:16.000 So you've seen like these building blocks. 24:16.000 --> 24:25.000 If you look at the mazel thing, that's the metadata thing that describes how to move around resources with their headers. 24:25.000 --> 24:32.000 Well, if you take a mazel and you take and you take the resources themselves, you can put them all in a big carbel. 24:32.000 --> 24:35.000 And that will give you like a self-contained thing that can like be shipped. 24:35.000 --> 24:46.000 But you can also put that metadata in a native proto record, save the 80 proto record with the, the, the robes that are attached to it onto your PDFs. 24:46.000 --> 24:53.000 And you've now shipped essentially a web app or web document in a way that is, you know, portable from PDFs to PDFs. 24:53.000 --> 24:56.000 And that is meaningful within within 80 proto. 24:56.000 --> 25:00.000 And you can use that to have apps that can be safely. 25:00.000 --> 25:10.000 And I, I insist on the safely aspect that can be safely embedded in social media context in chats a bit like WebX DC, etc. 25:10.000 --> 25:15.000 So that, that, that, that is also something that I'm pretty excited about. 25:15.000 --> 25:20.000 I, I almost have the, the demo working so we're getting there. 25:20.000 --> 25:24.000 So heading towards the, the end of this. 25:24.000 --> 25:25.000 Join us. 25:25.000 --> 25:27.000 It's a super friendly group. 25:27.000 --> 25:29.000 Like please, please, please, coming. 25:29.000 --> 25:35.000 If some of you have previously been in, you know, groups working on things that might have been a little bit toxic. 25:35.000 --> 25:39.000 This is the opposite of a toxic group, basically just hang out and it's friendly. 25:39.000 --> 25:45.000 And every month on the third Thursday, there's one of these two groups meeting. 25:45.000 --> 25:50.000 CID Congress is essentially the more community oriented one. 25:50.000 --> 25:52.000 You have a cool demo. 25:52.000 --> 25:54.000 There's something that you're working on. 25:54.000 --> 25:56.000 You do talk about it. 25:56.000 --> 26:00.000 Maybe you're trying to apply something and, and, and, you know, you're having problems. 26:00.000 --> 26:02.000 Come talk about it there. 26:02.000 --> 26:06.000 And dazzling group is if you want to dazzle the world. 26:06.000 --> 26:08.000 You're working on implementations. 26:08.000 --> 26:09.000 You're working on the spec. 26:09.000 --> 26:10.000 You, you have problems. 26:10.000 --> 26:12.000 You want things to change. 26:12.000 --> 26:16.000 That, that, that is, that, that is the general idea. 26:16.000 --> 26:20.000 But like, really, the community is like, you know, what if we did standards and it didn't suck. 26:20.000 --> 26:23.000 That's, that, that's how we trying to approach the problem. 26:23.000 --> 26:27.000 And with that, thank you very much for your time and attention. 26:27.000 --> 26:29.000 And let's dazzle. 26:29.000 --> 26:31.000 Thank you. 26:31.000 --> 26:34.000 How are we doing for time? 26:34.000 --> 26:36.000 Think we have time for late. 26:36.000 --> 26:39.000 I think I'll have time for just one or two questions. 26:39.000 --> 26:41.000 Any questions? 26:41.000 --> 26:43.000 What time? 26:43.000 --> 26:44.000 What time? 26:44.000 --> 26:47.000 Do you mention, and you emphasize, secure, right? 26:47.000 --> 26:48.000 Yes. 26:48.000 --> 26:50.000 What do you mean by that? 26:51.000 --> 26:54.000 So, uh, very good, very good question. 26:54.000 --> 26:58.000 Um, the idea to, with web tiles, what did I mean by secure and private? 26:58.000 --> 27:03.000 The idea is that when you load the web tile, you can only load the things that are pointed to in the manifest. 27:03.000 --> 27:06.000 And they only have access to, to that kind of function. 27:06.000 --> 27:09.000 So there's no exploitation of data. 27:09.000 --> 27:16.000 Um, and there's no ability to call, you know, a APIs that are not like explicitly exposed to, to the thing. 27:16.000 --> 27:18.000 Um, is it like, perfect? 27:18.000 --> 27:21.000 Of course, not browsers can, like, you know, have, have holes. 27:21.000 --> 27:25.000 But like the ideas really to create a composable web. 27:25.000 --> 27:30.000 And so that you can have one tile, even though it can't talk to them in that work once it's loaded. 27:30.000 --> 27:34.000 It could, like, load another tile with, like, an intense base system. 27:34.000 --> 27:40.000 And then you can start composing them because they can't talk to any other, um, system. 27:40.000 --> 27:41.000 True. 27:41.000 --> 27:44.000 And the other question. 27:44.000 --> 27:46.000 Yes. 27:47.000 --> 27:52.000 Let's assume your timber is the fact that in certain, you look at the CIDs. 27:52.000 --> 27:54.000 Why don't you put them in there? 27:54.000 --> 27:57.000 If they don't exist like that. 27:57.000 --> 28:00.000 So the question is, let's assume you timber is Lee. 28:00.000 --> 28:02.000 I can't imitate him. 28:02.000 --> 28:04.000 He speaks way too fast for me. 28:04.000 --> 28:09.000 As assume you timber is Lee, and why didn't you put CIDs in the web back then? 28:09.000 --> 28:13.000 I mean, honestly, you have to ask Tim. 28:14.000 --> 28:20.000 I think the problems that we're looking at and things we take for granted today, 28:20.000 --> 28:24.000 as issues of, like, the web or publication, etc. 28:24.000 --> 28:28.000 I think that we're less obvious back then. 28:28.000 --> 28:33.000 I think, like, Tim really, it's, like, you put stuff on the hard drive and you expose it, 28:33.000 --> 28:37.000 like, through a web server and then everyone can sort of, like, access it. 28:37.000 --> 28:40.000 And thinking about metadata was more his focus. 28:41.000 --> 28:47.000 Now, it's true that if you read computer liberation from Ten Nelson, he actually talks about how, 28:47.000 --> 28:52.000 when we publish, when, if, if ever of this hypothetical thing becomes big, 28:52.000 --> 28:56.000 we're really going to need some cryptographic proof that you got the real thing. 28:56.000 --> 29:02.000 And so it's not like the idea doesn't exist, but yeah, I mean, you'd have to ask Tim to be honest, 29:02.000 --> 29:04.000 at the end of the day. 29:04.000 --> 29:06.000 Hashing used to be heavy. 29:06.000 --> 29:08.000 These days it's okay. 29:08.000 --> 29:11.000 It would, it would take a while to ask your thing. 29:11.000 --> 29:12.000 Right. 29:12.000 --> 29:13.000 I think we're up on the side. 29:13.000 --> 29:14.000 Thank you, Robert. 29:14.000 --> 29:15.000 Thank you. 29:15.000 --> 29:16.000 Thank you very much. 29:16.000 --> 29:19.000 APPLAUSE