Okay, we're on time. I'm feeling amazing.
I've got to introduce Robin, who is going to dazzle us in all possible ways.
There might be some ways that I don't dazzle you in.
Let's just keep.
Hi, everyone. Thank you for coming.
It's a pleasure being here.
I'm going to introduce dazzle, which is essentially a toolbox to build other things with.
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.
But you know, let's try to at least make it bright.
And so this talk is pretty good if you like bright colors because you know,
and it tended to focus on, you know, brightening it up, brightening it up.
If you like acronyms, there's going to be a bunch of acronyms.
And they all mean something or almost all of them.
But also, like if you're interested in kind of addressing, you haven't used it.
Or you tried using it and it really, really sucked.
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.
And so what is content addressing?
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.
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.
And then you have that unique representation and you can get the content back.
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.
It's a very simple idea, but we can do a lot with it.
But before I jump in, I want to address the fact that dazzle is part of the IPFS suite of things.
We don't have a good name for the IPFS universe.
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.
But that's all is basically in that universe galaxy, whatever you want to call it family, big happy family.
And so if you think of IPFS, you can think of it as like a very very big system, I mean very big system.
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.
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.
And essentially there's a lot of implementations and they do a lot of stuff.
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.
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.
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.
Or because it has primitives that are very web oriented, I just noticed that that clock is dead, I shouldn't trust it.
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.
And I was like, ah, talking and talking, oh, shit, it's still 44 minutes left, I'm going way too fast.
It took me like, you know, a while to anyway.
That's not to that today.
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.
It has far fewer options, but the idea is that you can just get it off the shelf.
And the philosophy behind that is just to take a few very basic principles.
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.
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.
We focus on extensibility more than on optionality that might sound a little bit abstract.
But like if you look at CIDs, the identifiers used used in IPFS, they have a lot of options.
And that's good because it means if you need change over time, you can change how your identifiers are generated.
However, because everyone uses different options, or it's very easy for many people to use different options, people generate different identifiers.
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.
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.
But like we don't encourage optionality, most things have zero options.
They're just like have very, very, very set options, and we'll look at that in detail afterwards.
There's also a thing that's like, it's don't make me think, get the library it just works.
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.
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.
And this is what this is really what we're trying to avoid.
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.
Those are like, not great. This, they should work like, you know, out of the box in your browser as much as possible.
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.
It was the editor on the WC side of the HTML5 standard, which is something like 1200 pages.
Most of these are like, you know, one three-page standards specs. They're very, they're very simple.
And they meant to be like extremely basic functionality that composes well. That's how we approach it.
But, you know, enough of this introduction, here's like a few of the core specifications. So they're three core specs.
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.
So, consider the identifiers. Well, I mean, how many different ways can there be to encode a hash?
It turns out that it can be quite a few ways if you do it, like, you know, in a very open-ended way.
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.
But really, if you go to dazzling dots, the, hey, don't you love this serial hack. Anyway, dazzling slash the ID dot HTML.
You can see that a CID is, like, is very basically thing. It's always based 32 encoded. It's always v1.
It's at there, there are only two codecs. This is to point the Royce to point at, like, a resource like an image.
The structured data is to point at structured data, which we'll see on the next slide.
And the hash is always, um, a shaft I've 12 and it's always the same length.
The reason these options exist is because in the IPvs world, all of them can have different settings.
And so you can have, like, all kinds of ways of generating identifiers.
And in fact, in dazzle, there's one case in which we actually use a different hash type in one situation as an extension.
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.
And one of the things that's really useful in the content addressing system is deterministic data structures.
And so this is inherited from, if you're familiar with it, from the IPLD world.
And we have something called drizzle. And drizzle is essentially a deterministic variant of seabore.
Seabore is, you know, yeah, basically think of it as Jason, but it's, it's deterministic.
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.
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.
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.
And so that means that you can have a system that natively, even without understanding the semantics of what you're encoding,
can navigate the entire graph and find all kinds of other resources.
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.
It's like tag 42 is, is the, is the specific seabore tag for CIDs.
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.
A third core and the, that's like really the core of, of this stuff is like three tiny specs is called car.
Um, car is basically a very, very, very basic way of putting a bunch of content address resources into one single package.
So if, if you know, if you've ever looked at how tar works as a format, you can make tables with it.
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.
So that you know that you're getting the correct thing, um, and it's, and, and the length of the, of the content.
So basically you can simply like, like, skip, skip, seek and like verify on the fly.
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?
That's always, that's a key property of content address systems is that you can get the content from anywhere.
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.
So I'm not going to list all the specs in one go.
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.
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.
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.
So it's all drizzle drizzle drizzle.
All the blobs, everything that you, that get stored on there is, uh, a, a storeless CIDs.
And everything exports as car.
And when I say 80% of this is not something that's a Bruce guy only.
This is like the, the, the heart, you know, completely part of the protocol.
So I just listed a few random things, you know, black sky, um, leaflet flashed, uh, tangles senseo.
Like, these are like completely different applications.
They all use dazzle under the hood directly.
On top of that, of course, this is also used in a number of IPFS projects.
So, you know, everything that's dazzle compliant, uh, you can just, like, put it on Amino and it will just work.
Kubo supports it out of the box.
Next, an excellent work on CID profiles that help integrate dazzle, uh, even more easily in there.
And it's work with Iro protocols.
If you're familiar with the Iro library and set of tools that does that streamplace is in the house.
Also uses dazzle, um, and we're going to talk more about streamplace afterwards.
And so all of this is is is, you know, it's pretty, it's pretty, it's used at pretty real scales.
And there's a whole bunch of implementations.
And not can name check all of them.
If you go to dazzling, uh, to dazzle.ing, those are listed with links and, and more descriptions.
But this is to say that, you know, this is properly implemented with a test suite.
Um, that, that shows like, uh, imperfect, but very decent levels of interrupt.
And that, that interrupt keeps growing, um, very, uh, pretty impressively fast.
And so on top of that, because we made these like tiny specs that do the thing and that work,
there's some more advanced.
And when I say more advanced, they're really not very advanced.
Because everything's like a small tool.
But like they're more specialized.
You might think of them as like, uh, less, less widely used in CIDs,
but like more, more applied to specific cases.
And so for instance, Razle, because you want to Razle your dazzle, um,
is a retrieval spec for to get like CIDs, um, over, um, HTTP.
And the idea being like, yeah, if you're in the IPS world,
if you're familiar with that, the typical case, you don't have to do it that way,
but the typical case is you have a CID,
and you hit the public DHT, and you find someone who's, who's, who's publishing it,
and you get it from them.
We don't have that because there's no DHT, there's, there's no peer-to-peer layer in, in dazzle.
And so the idea with Razle is that you can have a link that basically has the CID,
as it's authority because that's what you're getting.
If you know where to get a CID, if you already have it, or there's any kind of retrieval method,
you want to use.
You'll find using that.
That's one of the things that's really powerful with content addressing
is it really doesn't matter where you get the data from.
So any implementation is free to like, optimize things away
and decide how it wants to, to find things.
However, if you don't know where to get that CID,
the link can include hints, and those hints will be HTTP endpoints
that are supposedly able to provide exactly that CID.
And the way you do it is that you just go to hdps hint slash dot well known,
slash Razle slash the CID.
And normally if the URL isn't lying about the hint,
working, you're able to retrieve it from that.
Again, this is a very simple spec.
You can, you know, it's a two-page thing.
There's, there's, there's an implementation of this for express.
I believe there's an implementation of this,
and I should get what other language for something else.
But like, this is a basic way of like exchanging data
and content address ways.
The idea is that this can be a brick with which you can build
very easy data sharing arrangements.
So that, for instance, maybe D trick and Dom and Marsh,
all want to have like, they make a little community,
and they want to pull their, their blogs or whatever.
They can all republish one another's data very easily
using this kind of system by syncing with one another
and then making it available.
You don't need like a complicated setup to to make that work.
Another chunk that's, that's interesting.
If people are standing by the door, this, this seats if you want.
Don't worry about it.
And so, another thing that's, that's interesting is so,
Mazel is the metadata spec for bundles of, of dazzle data.
And the idea here is that it's essentially like a web manifest.
It's drizzle encoded, of course, but it's essentially like a web manifest.
And the idea is that you can find resources by mapping that,
that this path to a CID in the metadata.
So this kind of look up, makes it, please, please, please, please,
makes it really easy to like have something that's web like.
So you have like an index.html and it's pointing to some images
and some JavaScript to some style, whatever.
And you put all of this in like, a big manifest like that.
And well, not that big into a manifest like that.
And you put them all like, in a car or something like that.
And you have the basically a self-contained little web thing that works well.
And this is sort of an iteration on the work that had been done over IPFS.
But like the idea of like having the full path encoded here means that you don't have
to like map it back to a file system and hope that the file system maps back to,
to HTTP ideas.
And also one thing that's, that's particularly important.
And one of the reasons why Mazel is very useful for web like web app like use
cases over content address systems is that the idea really with content
addressing is that again, you can get data from anywhere.
You can get the source from anywhere.
And you don't have to trust it because you can always verify that you're getting the right thing.
However, web content is meaningful in the context of the headers that deliver the resource.
And if you change the headers of a given resource, you might change its interpretation depending on which headers you changed.
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.
That guesses them or that just like comes up with random stuff.
Then you might find yourself with security issues or you might find yourself having interrupt issues.
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.
And you get the full basically HTTP envelope with the body included so that you can get something that's actually safe and interoperable.
And a third more advanced thing.
This one gets a little bit more complicated.
There's something called Bedazzle.
And I insist that you say it that way.
It's called Bedazzle for Big Dazzle.
And the idea is that instead of using Shopify 12, we use Blake 3 in this case.
So this actually uses different CIDs.
It uses a different option in the CIDs.
In a perfect world, we would have used Blake 3 for everything from day one, I think.
However, the paved the cow path idea meant that that was not compatible with the roof stuff.
And Blake 3 is still not supported in browsers so that that also creates problems.
So like this compromise meant that we use it this way.
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,
large, large, large, large, large.
But we can do streaming verification.
And I'll get to that.
It's something that we shipped, I think, what the 10 days ago.
10 days ago ish in Bedazzle.
It's the ability to stream verify verification.
And to do verification on chunks of range requests.
I'll get to that on the next slide.
Because it's also about future things.
So as I said, we have shipped Bedazzle support with Blake 3 and with a description of how you can do streaming verification.
But the system isn't completely finished in that.
Some of the bricks that I required to make it work are not completely specified yet.
The big value that you get here is like two primary use cases.
One streaming huge things.
So with content addressing, one of the problems is in order to verify that you got the right thing, you need the whole thing.
So say I'm streaming like a 20 gigabyte video to you.
You know, it lies maybe it's like 60 hours long and you like spent those 60 hours watching the video, etc.
Yeah, the other.
And it gets to the end.
And she actually got the wrong video.
And so it doesn't verify.
Now now I'm like, you spent the last 16 hours watching something.
You don't even know if it's the real thing.
What might have been hacked or whatever, right?
That's not great.
And so the idea with Blake 3 is that you can support streaming verification.
We've specified how our Blake 3CIDs map to the streaming protocol in Blake 3.
One thing that we're still missing is the sidecar.
We sort of like need a little sidecar that can give you a, basically, a miracle tree of hashes.
Everything's a miracle tree.
These days I love it.
And so there's this, there's this, there's the original thing called bow.
There's a, there's a more general thing called Bab.
It's likely that we're going to like sort of like mash up the two, two, two, two, two, do a bow Bab.
And, and another thing that I'm really excited about here and that the folks at computer zero have already implemented,
at least some of that in, in, in, in Iro is not just like streaming verification,
but range requests verification.
And so let's assume you have like a petabyte scale, you know, duck DB database,
somewhere on any kind of like HTTP server that supports range requests.
You can just like, you know, make a range request forward like the headers that give you the tell you how to find stuff.
And then you can just, when you make a query query by like doing range requests against that without loading the whole thing,
but while still verifying cryptographically that you're getting the real data whenever you make range requests.
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.
Another thing I promised you like more stream play stream plays.
Yeah, I promised you more stream play stuff or collaborating with our friends at stream place on something called stupa,
because again, we need, we need more accident acronyms and I have say that one that one is good.
What's the other one that we had like, oh, muxel tree because like it's a miracle tree of muxels.
And so the idea here is essentially to work on two things, those specs don't exist yet.
We're going to work on them pretty soon.
I mean, like the work has started, like you're going to start seeing some work soon.
One is you need deterministic MP4 containers because once you start putting stuff inside MP4 containers,
it turns out that the spec isn't very deterministic and it actually like tends to require things that are not deterministic at all.
So in order to be able to reproduce things, we need a specific way of looking at that.
And the other thing is sort of like a, can we call it a rent free c2pa.
Essentially, it's a subset of c2pa that doesn't require like buying into the novel certificate authority kind of kind of thing.
And so the idea being that you can like have like a chain of custody, a full video data with that.
And third one that's also also coming is web tiles and web tiles is that.
So you've seen like these building blocks.
If you look at the mazel thing, that's the metadata thing that describes how to move around resources with their headers.
Well, if you take a mazel and you take and you take the resources themselves, you can put them all in a big carbel.
And that will give you like a self-contained thing that can like be shipped.
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.
And you've now shipped essentially a web app or web document in a way that is, you know, portable from PDFs to PDFs.
And that is meaningful within within 80 proto.
And you can use that to have apps that can be safely.
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.
So that, that, that, that is also something that I'm pretty excited about.
I, I almost have the, the demo working so we're getting there.
So heading towards the, the end of this.
Join us.
It's a super friendly group.
Like please, please, please, coming.
If some of you have previously been in, you know, groups working on things that might have been a little bit toxic.
This is the opposite of a toxic group, basically just hang out and it's friendly.
And every month on the third Thursday, there's one of these two groups meeting.
CID Congress is essentially the more community oriented one.
You have a cool demo.
There's something that you're working on.
You do talk about it.
Maybe you're trying to apply something and, and, and, you know, you're having problems.
Come talk about it there.
And dazzling group is if you want to dazzle the world.
You're working on implementations.
You're working on the spec.
You, you have problems.
You want things to change.
That, that, that is, that, that is the general idea.
But like, really, the community is like, you know, what if we did standards and it didn't suck.
That's, that, that's how we trying to approach the problem.
And with that, thank you very much for your time and attention.
And let's dazzle.
Thank you.
How are we doing for time?
Think we have time for late.
I think I'll have time for just one or two questions.
Any questions?
What time?
Do you mention, and you emphasize, secure, right?
Yes.
What do you mean by that?
So, uh, very good, very good question.
Um, the idea to, with web tiles, what did I mean by secure and private?
The idea is that when you load the web tile, you can only load the things that are pointed to in the manifest.
And they only have access to, to that kind of function.
So there's no exploitation of data.
Um, and there's no ability to call, you know, a APIs that are not like explicitly exposed to, to the thing.
Um, is it like, perfect?
Of course, not browsers can, like, you know, have, have holes.
But like the ideas really to create a composable web.
And so that you can have one tile, even though it can't talk to them in that work once it's loaded.
It could, like, load another tile with, like, an intense base system.
And then you can start composing them because they can't talk to any other, um, system.
True.
And the other question.
Yes.
Let's assume your timber is the fact that in certain, you look at the CIDs.
Why don't you put them in there?
If they don't exist like that.
So the question is, let's assume you timber is Lee.
I can't imitate him.
He speaks way too fast for me.
As assume you timber is Lee, and why didn't you put CIDs in the web back then?
I mean, honestly, you have to ask Tim.
I think the problems that we're looking at and things we take for granted today,
as issues of, like, the web or publication, etc.
I think that we're less obvious back then.
I think, like, Tim really, it's, like, you put stuff on the hard drive and you expose it,
like, through a web server and then everyone can sort of, like, access it.
And thinking about metadata was more his focus.
Now, it's true that if you read computer liberation from Ten Nelson, he actually talks about how,
when we publish, when, if, if ever of this hypothetical thing becomes big,
we're really going to need some cryptographic proof that you got the real thing.
And so it's not like the idea doesn't exist, but yeah, I mean, you'd have to ask Tim to be honest,
at the end of the day.
Hashing used to be heavy.
These days it's okay.
It would, it would take a while to ask your thing.
Right.
I think we're up on the side.
Thank you, Robert.
Thank you.
Thank you very much.
APPLAUSE