All right, well we get set up here.
I want to go ahead and welcome Flores.
Flores is a software engineer at number zero and a mountain climber.
He's going to go ahead and talk about an introduction to IRO.
IRO is a rust library that simplifies P2P and networking by establishing direct QUIC
connections or quick connections, allowing developers to easily build the custom
decentralized protocols.
With that, I'll go ahead and over for us.
Give it up for Flores.
Thank you.
So yeah, I'm Flores and I work at number zero where we are working in IRO.
Iro is basically like what we want to make is like we want to create
a library to make P2P connections essentially.
We just want a connection.
Like we concentrate basically on the very basics of like you have two end points
and a connection between that.
But where are all possible?
Like we want to P2P.
So every endpoint can accept incoming connections.
Regardless of where you are located on the network.
And that's kind of the core of what IRO tries to do.
We use quick because quick is like fits very well for this.
And the end points we identify by this public key pair essentially.
And this means that the public key pair is actually the thing that you dial.
So you kind of have this notion of dial by endpoint ID.
And yeah, and that's basically the idea is that like this is like the core of like P2P networking
and then on top of that you can build your other application protocols etc.
So this is sort of the typical setup from that you get in the internet like you have two devices behind home networks.
And generally generally these are sort of behind not devices, not routers,
which means you can't actually make a direct connection to the other end.
Even if you have like IPv6 connection not may not be happening,
but you will probably still have a firewall in between there.
So this doesn't really change that much to it.
So what happens generally is that if you have two applications that when you talk to each other,
you end up with a server somewhere in a data center.
Apparently there's only one data center in the world, so everyone fails at the same time.
This is, yeah, this centralization is kind of bad.
And it's like ends up with too much failure and also like the server ends up knowing much more than it needs to,
generally.
And we would like really be able to, for the endpoint devices to be able to have control themselves
and really to have more like more user-in seeing that.
So instead of like what to make this possible, we kind of go to like the,
the I reliability essentially manages like how to create their connections and for that we need to open.
Now you see that we still have a real A server.
So how much battery is this really if we still have a server.
Unfortunately, there's kind of the reality of the internet.
You cannot like make direct connection without having some sort of server.
Like the, the problem is that you have like, you need a public IP address.
Like on the client side, you will always have to dial out and you need to have some public IP address.
The reason we actually like make this work is that we tried to make this real A server,
but it was a little less possible.
So the traders we sort of make is that we really want this connection to be a reliable.
Like if your connection is not like, if you can't always establish your connection,
then you're just not going to use it and you're going to go back to the centralized version.
So that's why we have this like as an absolute fallback.
There is a transport that goes fire the real A server.
The real A server is also like, and the other thing is like when you connect your connections.
If it takes like a long time, if it takes like five seconds to establish, that's also not very good.
So like right at the beginning of the connection, we will immediately start sending traffic through the real A server.
And then that traffic will help with the whole punching, and then hopefully you get a direct connection,
which will have much lower latency, et cetera.
What you can't really see on this picture is that the real A server doesn't like, it's not like one server.
Like everyone can host their own server.
It's kind of much, you think more of it as a federated network of real A servers really.
You're like, you can host your own server, you don't even need to know.
Eventually, when you need to connect to another endpoint, you need to know what real A server they are using,
but they could be using a completely different set of real A servers than you are.
Like we'll talk in a minute about how you find out where you can locate another endpoint.
And the real A server is also like very blind. It doesn't know anything.
Like it doesn't store anything, and it just sees encrypted data going from one node to another node.
So it has like the very minimal kind of information that it has.
So how this whole punch can kind of work with this is that.
We have so the last thing about like before going there is like the real A server also like has this.
You see here that it's like an HBS connection.
This is kind of like the idea of this is that like this is the connection that like.
Is the most likely to work on the internet regardless of how restricted kind of environment you are in.
We do want that a web soccer upgrade.
This is also like even if you have like very restrictive environments that do like machine in the middle kind of certificate connection hijacking to apparently security reasons but whatever.
Like there are often there are more likely to let through a web soccer upgrade than something else than a customer upgrade.
And once we have the web soccer connection, we can basically what we do is we put you the key packets that we normally send over directly the internet.
We put those inside that tunnel.
And the real A, the only thing the real A server does is like it gets a packet.
It sees what's end pointed is for.
And then it's then the only thing can go is like, well, do I have that endpoint ID connected to me.
If so, then put it over there.
If you don't, then just drop it on the floor.
And that's the only thing the real A can do.
So that's the only kind of knowledge the real A server has.
To actually do.
Hoping with this is like you start the way the way this works in Iro is that you.
You start the connection via the real A server.
And then you have to exchange like information about how.
How to establish a direct connection.
And basically you'll give like candidate IP addresses to each other.
So in this case, you have like the two external IP addresses that you would share.
Now when you do this, you don't actually really know if you're even on the same network like you could actually be local on the network.
So you actually just share all your IP addresses to the other side.
You send those via the real A connection.
And then once you both have the other kind of.
Connections, what you do is you kind of you send.
Packets to each other.
To all of those addresses at the same time.
And normally if you rejure firewalls, not devices, whatever.
We'll see that going, they outgoing packets go out at the same time.
And then they cross over somewhere on the internet.
And then when the packet comes back, when the other packet arrives.
Hopefully the router will kind of recognize this as being a income.
My packet from the same connection.
And that is kind of the basics of like how you do a whole bunching essentially.
So an arrow manages basically this.
Here does only like two paths.
When you do this in practice, you will get more paths than this probably.
Like a lot of times, we now have IP before.
And I do the six direct paths.
We might get both of them.
You could get even several.
An arrow trying to kind of tries to keep all of those connections.
And like selects the best one out of it that works.
And it's as soon as that the connection is established.
And as soon as like whole-pinching happens.
The relay connection will the relay path will kind of go.
Go quiet and not have any traffic.
So and the relay server doesn't even because it is completely blind.
It doesn't even know that whole-pinching was even attempted or succeeded or anything.
All it knows is that sometimes there's a bit of traffic sometimes there's not.
So you still have to find out where you're on your endpoint.
It's like because with dial by endpoint ID, which is line of the public key of your cryptographic
And for that we have to have.
Yeah, for that we have to like have we have a system basically.
It's currently called, well, we just renamed that actually in the last release.
It's now called address lookup.
And the basic idea is that you map your endpoint ID that you have.
And you want to find out like where I find this.
Maybe it's on a relay URL, which is kind of the typical scenario that I just described.
But it could also be like you could be on a local network somewhere with no access to a relay server.
That's like cut off.
So you could also resolve into IP addresses, directly, etc.
And this kind of is modeled on like DNS resolution, like DNS lookups,
which is kind of very similar way you have like a name and then you need to find some IP addresses.
And this is also like why, how you find like the relay server of the other endpoint,
without having it configured or needing to have to not know it ahead of time.
The nice thing about this is that this is like completely accessible.
So you can like depending on the application, you can extend and add your own address lookup.
For example, like the gossip protocol that I will quickly mention at the end as well.
That has its own, or adds its own mechanism to this, because it kind of already can find out information about other endpoints out of band of,
so it can already provide us.
The most common one that we can recommend is actually literally DNS.
There is very nice system, PKAR, AR, Pika.
And what this actually does is like, it's a very small and needs standard.
It's not like, that essentially is a mechanism to like publish some information that is like signed by a public key or a key pair.
And like, this essentially there is like, we have basically, and you can, again, this is like, you can run your own DNS server for this,
but we have the DNS server running, that basically at a sub domain, you can basically ask for like, this is the idea I'm looking for,
and you get back here DNS records.
This DNS record is kind of signed by the key itself.
So the server, like to submit, there's you have to publish this on to an HTTP server essentially,
but this server will only accept these records, like, if you can actually, if the signature actually is valid.
And actually, when you look up here, you also have this kind of system.
DNS is kind of nice, because it's like, how would you, a lot of the internet is worked for this,
you get all the caching, and such are going on in there, so it's like a very nice way.
And DNS is like an all the very popular way.
It's like, looking at work only, and you basically broadcast, you like, the notebook network saying, like,
can I find, is this no idea here or something?
And the DNS one is kind of funny, because it does something extra that's no part of Android's look up,
because, like, if you familiar with MDNS, a lot of people actually expect to just, like, magically know what other devices are in the local network.
And, and DNS does this by basically broadcasting every software, and here I have this service kind of thing.
So, so, yeah, if you use the DNS address look up, you have this a little bit of extra information that you can use as well.
The same PCAR system that kind of allows you to publish DNS records into the DNS system actually allows you to publish it directly into the DHT as well.
But the bitter and mainline DHT is kind of the DHT that has been around for a long time and survives a lot of attacks such as that to it.
So, it's like a very reliable DHT, and the nice thing about the PCAR is that it can publish directly onto DHT.
So, if you don't want to have any central services to try involved, this kind of also shows that this is possible.
Depending on your choices, right? And, you know, free to, yeah, you can make more of these.
I'll go very quickly through, like, basically, once you have a connection, right, you have, we basically provide a quick connection between two endpoints, and that's it.
Then it's up to the application to kind of decide how to do quick is kind of very nice with this, because it is build on top of UDP, which is,
which is very nice for, for whole-pinching, etc., so it was kind of nice for us.
But it provides also a kind of a familiar interface to the application developers.
So, basically, you get, like, streams, which is, like, order data, like, you get a TCP one.
The stream, you get more than one stream though, like, in TCP only get one.
And the nice thing about, like, if you know, buy a HTTP too, there you also have, like, multiple streams, but you kind of have a headline blocking where if you use some packaging one stream, all the streams are blocked.
In quick, it doesn't, doesn't have that problem anymore.
You also, there's a data-grams extension, and these two together means that, like, if you have an application protocol already, that's, like, on TCP or UDP, you can just bought them and, like, use quick, very nicely.
Quick has a lot of other nice improvements though, like, especially the connection handshake is, like, much faster.
If you do a connection handshake in, like, TCP and TLS, you get, like, three round trips to, between the two endpoints, before you can start sending data to, application data to, to the other endpoints.
In quick, the normal handshake, the long handshake, kind of, is just one half round trip.
Like, quick manages to combine the TLS setup and the connection handshake in, together.
And, like, you just send one packet to, to the remote, you get one response back, and then you can send an application data.
Once you have, like, managed to have a connection, and you reconnect to the same, to the same endpoint again, you can even use zero RTT, which basically means that you can,
but that use the data application data directly in the first packet.
Underhoods, like, there are various other things, like, lots of detection, congestion control is very nice.
It's always encrypted, and also, like, it's always encrypted is kind of, so TLS is, like, mandatory.
And, everything is, like, encrypted on the packets, like, so everything on the wire, like, there's, like, just a few bits in the head,
basically, that are not encrypted.
Everything else, like, including the other, including the, yeah, all the connection metadata is fully encrypted.
The purpose of this is partially just to make everything look like the same, like, you cannot tell anything.
TCP is, like, very occupied in a way, it's very difficult to evolve.
Yeah, the hope is that this will stop middle boxes from being relying on particular properties of quick.
But also, the other nice thing is, like, everything looks like H2B3, essentially.
So, the more we get H2B adoption, the more everything just looks like, the same data grams around them, you need to be packets flying around.
Which is kind of, like, a nice thing to aim for.
So, once you have your quick connection, basically, arrow kind of gives you, like, once to provide you, like, the model of protocols kind of.
It doesn't force you, like, to use just one one application protocol, like, we provide, like, we kind of try to make it easy enough to, like, use multiple protocols.
So, you can establish multiple connections and each endpoint can, like, implement various protocols.
So, I will quickly talk about, like, two of these protocols that we ourselves built.
There are, kind of, generic building blocks.
There's, yeah, you're not, of course, you're not limited to, to, to any of these.
But, yeah, blocks is sort of the, the protocol that we have for requesting, this is kind of verified streaming.
So, the idea is that you, you get your, as, as you, if you fetch a file or something, you want to download something,
that as data comes in, you continue to know that this is, like, the correct data comes in.
And gossip is kind of this, this way of, like, creating a swarm and, like, without having to have a direct connection to every member in this swarm,
you can, like, send small messages to the entire swarm.
So, very quickly kind of going through these, it's just, yeah, it's kind of neat protocol, I guess.
It's, um, blocks is kind of built on top of Blake 3, which is a modern and fast hashing algorithm.
And, um, yeah, and Blake 3, basically it uses the internal structure Blake 3 to, to enable this.
So, what Blake 3 does is, like, it, you, you, you, um, partition the file into, like, one kilobile blocks.
And each block gets it and hasht.
The reason that, this makes Blake 3 really good for optimizing, because you can, basically, do this in parallel, which is in the instructions, et cetera.
And then once, once you start, once you have all those hashes, you can start, like, combining, like, your hash basically two of these hashes together.
And that make up the next layer of hashes.
And you keep building up this, this, um, these hashes all in into a circle 3 essentially, uh, all the way until you have, um, a root hash.
Now once you have, like, you, you, you have managed to build this all the way up to the root hash.
To do this or the verified streaming, what you have to do is you have to traverse the hash from, from essentially the top to the bottom and the left to the right.
So you start with the top 1 and then you go, um, you, you send the, you, you send the, you're, you're, you're, you can check those, your hashes in that make up that day.
It's still make up the root hash.
Then you basically keep doing that and you keep going, you go to left.
You send those the hashes.
Then at the end you end up on the, at the bottom left and you actually find send the file chunk.
You've sent very little data now, but you already know that everything that you have sent at any point, you received something.
You know that is valid data.
You can go through a line to draw a file or you can do also it's really need to do ranges as well.
So you don't have to like build the entire tree. You can like go through them.
And this kind of shows the order in which you would send kind of this chunks.
And you would always kind of be able to verify data.
This means you can like, yeah, fetch files with different chunks from different endpoints, etc.
Which is kind of very neat.
Very quickly, I think we probably have a minute left to it. Something one.
Okay.
Gossip.
Yeah, the gossip is kind of like it's a implementation.
There are many gossip innovations with different trade-offs.
This one is sort of based on spikes written by the Willow folks.
And it's very efficient that it's like just a bit of a message to dynamic gossip cluster, I guess, or a number of endpoints.
But it's not necessarily the most like attack resistant one.
If you have malicious notes and part of that, you might want to reconsider this.
Very high view kind of is like it's built on like two separate systems.
One is like where you have like a handful of like neighbors, which are just randomly chosen essentially.
And whenever you have a message you send it to all of those.
But that doesn't scale up.
So like if you do it out through the whole swarm, that you get a lot of duplicate messages you're being sent around.
But the active neighbors allow you to find quickly like, or become member of the group.
The passive neighbors are sort of like in case you lose some active neighbors.
You immediately have other ones you can replace this.
And if you have too many neighbors, they get handed off to another node and that kind of thing.
And then on top of that, the plum tree part is like building a spanning tree.
And that's actually what you're doing.
You kind of continuously make sure that there is a single tree of like where message can be passed through to be delivered to every member in the gossip swarm.
So you have to continuously prune and make for repair links in this tree you're to draw.
That was very, very fast.
But yeah, hopefully it gives you an idea of like, let's help.
Thank you for a sweet appreciate you coming in here.