0:05 From node to node, we light the wire no central tower no empire. Across the noise through netting rain Iroh finds the path Again, keys in hand and trust in sight Encrypted streams across the night Local first but world aware Peers can meet from anywhere Brendon O'Brien takes the lead, walking through the code we need. Peer to peer, but clear and clean. Showing how the pieces mean. Bring the demos, bring the code, build the network, Hello. Welcome back to the Rockcode Academy. This is another episode of Rockcode Live where we take a look at awesome open source cloud native and cloud native adjacent projects. Today is no

1:43 exception. We're taking a look at a wonderful project called Iroh and we're going to be guided by my wonderful co host for today,Brendan b five. Hey, man. How's it going? Hello. Hi. Nice. Thank you so much for here, David? Yeah. Thanks so much for joining me today. I'm really looking forward to digging into Iroh, and I'm gonna do my best to say that the right way every time. But I feel like though now that I've called the Iroh once, it's just gonna slip out a 100,000 times. So don't be Yeah. It's it's so good. Yeah. It's a word that you see on the Internet. I'm not offended

2:14 by any means. I'm still too busy giggling at this intro song. I don't I don't know if I'm gonna be able to play it, but really it was adorable. I think, you know, AI is is changing the way that we ship and write code these days for some people. Some people would prefer to have say and that's okay. But I do think that from a creative point of view, I'm not a musician, I can't play instruments, at least I try to play piano but very poorly. But being able to just, you know, be able to prompt something like that is a a little fun intro. It just

2:45 amazes me every single time. I mean, I I got a laugh out of me. And so, you know, that made my day. Awesome. I well questions about the efficacy of whether or not they're actually centered servers in the middle and we'll talk about that. But it's still a solid pop punk ballad. Yeah, man. Well, yeah. We're gonna get into the technical details. But before we do that, could you just please take a moment to say hello and introduce yourself to the audience? Totally. My name is b five. I have a real name. It's Brendan. I've been working on for a

3:18 long time and have the sort of distinct pleasure of getting to rep a lovely group of people at a company called NumberZero. And we make this open source project called Iroh, and it's all about networking. I'm sure we'll get into it. But, yeah, I've had a lot of you know, I started out as a graphic designer, and people kept getting my mock ups wrong, so I learned what HTML is. And then fast forward fifteen years later, and I'm gonna talk to you with a compiling REST and see how this I've I've I've had a maybe it's like a slide down the rabbit hole that just has never

3:48 stopped. But, yeah, it's been it's been quite the journey, and it's delightful to kind of get to work on the Internet as a job. So yeah. Wow. Graphic designer to Rust code. That that is Yeah. It's like it's a it's a big delta. It covers a lot lot of space. But if you notice me, like, having really strong opinions about my, like, code editor's color scheme, it's earned honestly. But, yeah, it's yeah. The more the deeper you go, the more fun it gets. So now I think I'm done at Rust. I think that's kind of like, I don't need to, like, manually manage

4:23 my own memory. I think, you know, I won't have enough to learn the c mother tongue properly, but, you know, we're we're good. I think I found the bottom. Nice. I I know, as I said, very creative person. I've always been a kind of back end developer. I've always shied away from from front end. In fact, my idea of a website was always black text on a white background. And so I find that amazing that you can go from that journey of someone who is creative and visual to now we're gonna write some Rust code. Like, that to me is mind boggling. So I mean, more. I

4:56 mean, if you're, like, a details oriented person and you really, like, start with, like, oh, let's make sure that this layout is, like, pretty, and then you end up with, well, you know, if the layout's done with CSS, then you have to learn CSS. And if, you know, eventually, that gets boring and you fall backwards, know, start worrying about how async runtimes are implemented. There's some steps in the middle that are skipped, but, you know yeah. Right. Well, I don't wanna labor on it too much, but I'm gonna just point out one more thing about your journey. Again, graphic designer, let's just ground out there. Not only

5:28 just to Rust, but to networking primitives as well. Right? Yeah. Yeah. Yeah. Yeah. We we had a we spent a lot of time working in the distributed web movement, and there was a lot of time there where the core thing that we observed a bunch was a bunch of folks who are really, really, really smart trying to build really awesome, like, just like advanced Internet stuff. And one of my like, the quote that sort of still haunts me forever is a couple of folks saying, we're still stuck in the food, water, and shelter phase at the time, and this was four or five years

6:01 ago. And just like literally, can we get two devices to connect to each other? If we could do that, we we would unlock all kinds of amazing potential, but we just couldn't reliably connect stuff. And we couldn't reliably connect stuff in a programmable way that would let us sort of experiment with some of these really fun distributed systems sort of things. And and so, yeah, we just decided that, like, we should really work on networking. And it it wasn't like a super you know, it's not you know, we're not building an LLM from scratch. It's not, you know, the soup du jour, but we really care about

6:32 it. And we spend a lot of time here just because we know that or we feel very deeply that there's a need for, like, a really solid networking primitive that can let you kind of question the fundamentals. Like, I don't know. There aren't, like, a lot of, like, hey. We're a networking company these days. And so it's I think it's been a lot of fun. There's a lot of room for us to move and play and grow. And so we've been we've been having a blast, but it's definitely, like there's, for everybody that starts in the reserve, there's kind of this initiation time where it's like, okay.

6:57 Cool. You really are gonna have to, like, learn to care about packets and timeouts and things that just, like, most humans don't have to bother to think about because somebody else did it at some other point. Yeah. That's an that's how we ended up caring. It's just like we realized value in getting this right. So we think we've got it right. But yeah. Well, I don't know whether to say, okay, do we discuss what Iroh is or do we focus on the history of it? So I'm gonna come at it from a weird tangent and you can shoot me down if you want. Right?

7:29 But let's talk about how network is currently. Let's just say broken to a certain degree. Right? Totally. Can we not just as people are born, tattoo them with an IPv4 address and say that is your IP address for life? Yeah. I mean, then I mean, the implicit the implied conclusion that you're saying is there's only gonna be so many how many IPv four addresses are there? Like, you're basically capping the human population right now. So, like, we if we could, you know, maybe, yeah, but like One n one o. Right? I I wouldn't I I mean I mean, it yeah. No.

8:04 No. Yeah. I I don't know I don't know that I'd be down. I'd want what if I wanna change my identity? I then my, like, view is not Yeah. I mean, you could you could, like, go on a black market and, like, you know, sell your IP address to get a vanity friend's IP. Yeah. Yeah. Yeah. Like It's like Geocoding takes on a whole new category. Yeah. No. I I I gotta say I wouldn't do that. I would I would do something else. And I Yeah. We can talk about why ephemeral keys are probably a little better. Alright. So we don't have enough IPv

8:36 four. We've got IPv six. Okay. So yeah. So been so successful. So successful. Going so well. It's going so well. Yeah. You know? 2026, we have self driving cars. It's gonna be great. Yeah. Then we can talk about, you know, that if we really wanna go down the deep end and talk about the wonderful fun things of networking and spanning tree. But I'd rather avoid all that because Iroh has what I think is something slightly novel. So let's lean into that. What what is Iroh? Let's let's Totally. Yeah. And so, like, you know, I think I like I like the setup. It's a and and I well,

9:09 I wouldn't tattoo numbers on people. I do. But there's some, like, broken things about about the Internet. And, like, I think there's this really funny you know, with Iroh, we're trying to get you to have a bit of there is no spoon moment. And you for the entirety of our professional careers, if you ship a web application, there's a server and there's a client. And what we're trying to get everybody to understand is, like, those you know, you sort of don't imagine your software is being deployed until it's somewhere that it's running in, a publicly accessible place. There are there are special IP addresses, and those special

9:41 IP addresses are special because they're publicly dialable and they're steady. And Nope. That's kind of ridiculous. Like, we can we can actually do a lot better than that. And so Iroh is a networking library. The thing that you do with it is you put it inside of an app, and the thing that it does for you is you can connect any two devices anywhere on the planet with a secure tunnel. And that's that tunnel is actually a quick networking stack running TLS, running all of the things that you would expect from a modern networking implementation using as many IETF standards as you can throw a

10:14 stick at. And as that if one of those devices is a cell phone and it's moving, it'll stay connected. If one of those devices is an InfiniBand server and it has a better direct connection to some other InfiniBand server in the same rack, it will find that direct connection. It will use that. It is intended to run on extremely low powered devices. We can run on ESP 30 twos. Then extremely high powered devices, you can do hundreds of thousands of millions of concurrent connections with enough hardware. And so the idea is, like, genuinely, instead of, you know, just importing your normal standard library net package, you should

10:46 think about importing Iroh, and now you have all these new sort of tools in the toolbox to work with. You can directly connect devices. You can those connections are always end to end encrypted. And so now you have the capacity to have, you know, users of your application talk to each other, and they can talk to each other in more interesting ways. And that can achieve a much more interesting network. It can be a lot faster because latency can be lower. People that are physically closer together will get a better connection to each other. You can do stuff like connecting your devices together into a natural family,

11:15 you know, your phone talking to your laptop, your laptop talking to your iPad. That's all, I should say tablet. But, yeah, all of that's in the realm of possibility with Iroh, and we want that to be a library that people program with, that people play with and build on top of. It's not to say that you should stop using servers. Today, I wanna show you some examples of how we could just do server and client and don't have to, like, overthink things. But I think there's a whole bunch of value in the idea of asking more of our networking stacks. That's what we're trying to do with

11:47 our own. I'm supposed to say at this point that the whole project is totally open source, just so that you know. But it's an open source project. Yeah. Plus, you know, it doesn't hurt just to say Rust a few more times as well. Yeah. Rust. Rust. You know? And, yeah, rewriting everything in Rust. This was written from the jump in Rust, and and that's yeah. And I'll today, I'm gonna show some Rust. The actual library itself supports a number of languages. The way that we get to that support is through FFI fundings. And so when you're using Iroh, Python, it is actually talking to the Rust implementation,

12:17 which makes it snappy and quite nice. And so we support, like, Kotlin, Python, Node. Js. We can compile into the browser, so this can all run-in a WASM build inside of a browser. We can run-in lots of, yeah, Swift, Go, and the Go Go support is community contributed, which has been very fun. Yeah. But like a bunch of the kind of major player languages. We don't support Zig yet, but we'll have to get to that some more. I don't know if you've been following the Bun rewrite from Zig to Rust. A little bit. I was just I was just scrolling Twitter drama

12:54 before this. And But the Zig founder published a blog, I think it was actually this morning, with their kind of response to that. And I I didn't think it was the best response, but that's not the point of this conversation. It is not. And I and we're gonna choose to remain completely professional about all things and say that things are great language. Best of luck to you. So let's go back to Iroh then. Sure. What I really want to know is I wanna understand it from two different personas. As a Internet or, you know, as an a consumer, as a product, someone who's going to

13:27 use products that may be powered by Iroh, what does Iroh mean for me? And as a developer, what does it mean for me to adopt Iroh into my my project. Right? So if we can tackle both of those, I'd be very, very happy. Totally. I think that's great. From the consumer perspective, you are going to get the at least what this depends on whether the developer decides to give it to you, but you can own your software again. You can actually get back into a place where what Iroh is fundamentally doing is moving a lot more capacity

14:00 to understand networking conditions to the edge. Right? So an Iroh endpoint actually understands when it has a wide area network connection, when it's in a captive Wi Fi portal. It understands when it has an I p p four address, I p p six address. It understands when it's on cellular, and it will adapt to those situations automatically. And that software goes inside of the application that is shipped to you. And so the win of that is you can now you know, we had this phase before all software was assumed to be networked where you you know, this is way back in the day, but, like, people would,

14:28 like, buy, like, $50. You CD ROM, you download it, and you owned that software. And now because things need to be networked, we need servers. And because servers need to exist and need to be very sophisticated, have we to buy subscriptions to those things. And that's not inherently bad. But the the thing that's exciting is when the edge is far more sophisticated, you can make way better choices about how your networking stack should work, and you no longer have this necessity of a thing in the middle. We we'll talk about how Iroh works under the hood. It does use servers. It's not a completely serverless solution. But

14:59 the servers that we use are very, very dumb. They actually don't need to contain any application logic whatsoever. You can put all that application logic in the client and in one codebase that you can ship everywhere. And so the thing that a user will get is and that is also just leveraging the existing networking that's around you. So, you know, when your phone is talking to your laptop inside of an app that you've shipped when when one of your users' phones is talking to their own laptop inside of an app that you've shipped to them, that is just that can be just their router at home. And

15:26 that's as efficient as we can make the Internet. Right? We're in a place where now, oh, wow. Like, we literally are disturbing the fewest set of electrons we could possibly disturb to make that thing work. And so they're going to get a faster experience. They're gonna get a more more secure experience. As we all know, latency is the mind killer. Right? Like, under you win it when a server is too far away. You're not gonna have nearly as many of those phenomenon where you're gonna need to dial something that is across oceans just to make your app work. And so you get think this is a capacity

15:55 to sort of, like, dramatically improve both the set of things you can have as a user and the quality of the experience itself. We genuinely think you can do both. Now if you're a developer and you're building, you kind of get to choose your own adventure on how intense this gets. And so the most simple version of this is if you imagine just designing for yourself a simple JSON RPC API, Just using HTTP, you're using gets inputs, you have servers and clients, posts and deletes as well. But you can with Iroh, you can just take all of that procedure and wrap it in Iroh

16:34 as direct connections and kind of treat it like a dumb pipe between devices and just shove your stuff inside of there. Iroh can give you something that looks a lot like a TCP socket, which you can then wrap in HTTP. And you can literally just say, cool. That's it's the exact server that I wrote already, and I can now just pipe those bytes between each other. And we have lots of examples of how people will do that, and we that's usually where we start with a project that is adopting Iroh that already has some existing stuff. But if you're starting from scratch, you can do all kinds

17:00 of really interesting things. And the most interesting thing about Iroh is this idea of dialing by key. So in Iroh, we don't actually use IP addresses. We use keys. We'll get into that a little bit in a second. But that opens up all of these really interesting things where you can say, these users have these endpoints which are addressed by these keys, and we can start doing permissions and capabilities between them. And those can travel. They can survive not being able to maybe phone home and still enforce permissions. And those connections are using that same key for the encryption. And so that is constantly being reaffirmed, and

17:33 you're not paying a double tax on that. That's actually just TLS doing its job. And so we have some really cool tricks. We think it's a really slick abstraction for you as a developer because you no longer need to think about IP addresses. We don't have to tattoo anybody. We can just say, here's your key. You can you can have as many of them as you need. And if you wanna keep one around that represents your your device or one that is associated with an identity, that's totally doable. And this is different from the way IP addresses work, where an IP address is given to you by

17:59 your router. Right? In this world, your application declares, no, I have this key, I'm going to move it around wherever I want. You shouldn't move them across devices, but that device can move physically wherever it needs to go. And you no longer need to worry about, you know, am I is this server in GCP or AWS or whatever? Just give them all keys. Connect them up with the keys. Call it a day. Right? And that, in our world, is a much more when your app now all of a sudden owns the stability of that, you get a much easier to reason about DevOps experience, and we think

18:29 that's a really exciting thing. And then we can get into, like, all the distributed system stuff we can do on top of that, but, like, we can also just park that because it it gets the the rabbit hole gets very deep here where you can you start building, like, consensus things and broadcast mechanisms. You know, that's all on the table, but maybe that's sort of the 200 level course. Alright. Well, I mean, I don't think we should dismiss the tattoo and idea so quickly. Let's just leave it over there. Okay. We'll park it. We'll park it. Yeah. Yeah. But okay. When I think

18:57 about, you know, networking applications, you know, we're still I still think today it's an IPv4 world. We have DNS system to get names and IP addresses and we have, you know, autonomous systems in BGP to find routes across the Internet. Mhmm. What changes when I adopt Iroh? I'm assuming the keys aren't is there a DNS server that resolves keys? Do we have BGP for peering? How do we do discovery? Like, what's going on behind the scenes? Like, what is the end Absolutely. Of This is a great question. And I think this is the first thing that we like. We need to spend more time

19:32 here. There is no like, you don't you aren't act you aren't actually dialing the key. There's no like, we didn't, like, deploy a new Internet of hardware, you know, overnight. So instead, we go through this process. We call address lookup. And address lookup takes a key and converts it into something you can dial gets the IP address. But most specifically, what it actually gets is the home the URL of the home relay that that endpoint is reachable at. And this is where we do need to talk about relays. But before we get there, to answer your question directly that that how do I turn a key into

20:03 something I can use? We just use BoxCenter DNS. Well, actually, we use a custom DNS server, but actual normal DNS. And so when an endpoint gets created under its default settings, it will we we have a set of presets. We'll talk about that. But, basically, you you need some way to convert addresses into into full or you can turn I endpoint IDs, the keys, into full addresses. Then the the default one is this DNS server. There are others. It's a pluggable trait, and so we actually support the idea of using things like DHTs for lookup. You can also use so you can actually build entirely offline versions

20:37 of this. But the core thing you need is that capacity to say, hey. I have the following endpoint ID. I need to turn it into some something I can dial. And the bog standard way that most people do this, when the endpoint starts up, it takes its own endpoint ID. It figures out its home relay. It then creates a DNS record and signs it and hands it to a DNS server. And that DNS server then will rehost those as long as the signature is valid. It will say, cool. You you clearly own that key. You have the private half, and so you can make this claim that

21:05 this is true, and I can verify that. And so I will list this in a directory that if somebody else has your key, the public half, they they can look you up on this DNS. They could do a DNS look up, and that will return, oh, that that endpoint ID's home relays over there. Yeah. Does that answer the question? It's it's kind of a you know, it's it's a bit of a sleight of hand, but we we try not to use, like, fancy things here. I guess the question I have in my head is, does the Iroh project or, you know, your company run

21:37 a set of relay servers that are there to provide the backbone of the Iroh network? Absolutely. So let me I I should show you. I think actually an example might be the best for that. Here, let me pull this up. And so I'm just gonna, like, write the example that we were gonna talk about in a second because I think it is worth, like, getting into this from a code perspective. So I'm literally just gonna, like, you know, type up. I apologize for jumping straight into Rust right away on the. So but, like, with Iroh, this is how you create an endpoint. You do yeah. In Rust,

22:12 you do var endpoint equals Iroh endpoint bind. And you need this thing called a preset. And so I'm gonna do Iroh endpoint resets n zero. This, if you go look into the documentation for this, this is saying configures to you to use the n c to the DNS address lookup service, the default relay server is provided by number zero. This is part of the reason why the company is named different from the project. And so when you see number zero stuff, this is stuff that the actual organization is providing. And and then we also, you know, we set you

22:47 up with Rust TLS and some other things that you should use properly. And so we then type bind await and then this assuming that I I have to do let. Sorry. I'm flipping back and forth between JavaScript and but, you know, this is gonna give you an endpoint. And so this this n zero is just to directly answer your question. You we intentionally changed the API just prior to one dot o to force users to, like, know what they're opting into and what they're choosing as a dependency. Obviously, you can deploy your own relay servers. The relays are, you know, totally

23:22 public. And so the actual server binary is sitting Iroh Relay. It's right here in the main repository. And and as is the DNS server. Right? And so you can run these yourself. We also offer a hosted service. We won't get into that, but we do that, and you can spin those up. And when you do that, you will get your own relay presets, and you can set it up here and basically plug in your own infrastructure. And so Iroh does use infrastructure. We intentionally try to make sure that you know what you're opting into, but these we run for free. And you can run this without

23:50 any account, without anything. Because it's an encrypted and these serve these relays and this address lookup is incredibly dumb, we don't you know, this is just a kind of part of the free service that we run. And we think it makes it easier to get started with Iroh. It's a really great place to sort of just, like, be able to mess around and not have to worry about, like, do I have this account? Do I have that API key? You just use these servers. It's totally fine. More people than it would more people than I would like to admit have have put this into maybe not production,

24:17 but, like, production adjacent use cases. And so we've we've you know, these these relays have seen on the order of, like, 30,000,000,000 endpoints created in the last six months. There's we've never had a traffic problem that this Rust is very efficient, but and our team is good. Actually, it's not just Rust. But yeah. Does that answer your question? And, hopefully, that kinda gives you, like It does answer my question. Yeah. So Okay. I say I want an endpoint. I can publish it to my own relays, or I can use the ones that come out of the box by a number zero. So And that process will look

24:51 a little like this on startup. I can just show you this GIF. This is like when it starts, it'll ping all these relay servers. These are intentionally geographically distributed. The endpoint, this is that kind of intelligence in the edge endpoint that we talked about. It'll figure out, ah, US East has the the fastest ping, so I'm gonna choose that as my home relay. And that process all happens when we when the process boots up. And so we get into, like, endpoint. Online, and then we await this this after this returns actually, this can fail. You now have a public relay server. Now we have a relay.

25:24 In this in this moment, we're still starting up in here. Okay. So as part of this, preset and we've got the relays and there was a DNS bind as well, and we also spoke about private keys. You haven't Mhmm. Generated any x five zero nines or private keys that I'm aware of. So is this just all abstracted away? Or That's great question. So under here, we can actually come into this builder and do I think we'd have to do Iroh endpoints builder, and then we can do I have to do a builder here. It's been a second.

26:04 Sorry. Let me just answer the question directly first. The what what we do this by default, this this, like, bind out of the gates, actually sets you up with an ephemeral key. And so Iroh only uses e d two five five one nine keys in mutual TLS mode. And so, Ed, to your exact point, there's no certificate chains happening here. Mutual TLS means both ends are agreeing to speak to each other as outside of certificate chains. And so when endpoint bind fires an actual we actually generate a secret key right out of thin air. We use it long enough to run

26:39 that one process, and then we when the process shuts down, it's completely thrown away. And so we call this an ephemeral key. And this is good for, like, if you want client requests that you don't want to be traceable or anything, and it's it's very natural, but you can also attach a a persistent key to it. You can say, hey. I want you to use this key when you dial stuff, and that's usually where you end up with persistent keys, and then you can attach permissions to those. And that's a a different process. But the the Iroh will always needs that key to start and

27:06 that key is kind of the core foundation of everything. Okay. Would it be fair enough to say, you know, ephemeral keys are fine for some application use cases? Maybe it's like networking, you know, temporary ephemeral channel, this. But if I wanted to run something long term, is this where I would bring my own key and say, is my private key? Yeah. And and we provide some utility functions for that, and then the our util crate has this kind of, like, you know, persist this key, store this key, and re resume it. And, usually, you'll just write that to a file system. And so,

27:39 like, you're in a much more, like, classic application where it's now gonna store some state, but cross process restarts. And so now you wanna make sure you restore that. And that yeah. And so the the analogy that I like a lot is your browser actually has a set of keys in it as well. Right? And that's stored in a secure enclave or not secure enclave. That is stored in a secure part of the browser that it won't just give those keys to you. They don't move, but it can regenerate them randomly. And so you don't actually don't you don't see this infrastructure a lot, but it this

28:06 is very much a part of the modern web. Like, even when you're talking to the classic search chain style, hey. I I know that I'm speaking to this domain because it has an HTTPS certificate that's part of the ICANN certificate chain. You even the clients are actually just generating client identifiers to be able to facilitate that connection in a nonmutual form. We're just now doing that on both sides. Nice. Yeah. Alright. We have a couple of questions. I'm wondering you kind of mentioned. So someone did show up a little bit late. Don't worry. We're not judging you. They do want to know

28:39 whether we discussed the underlying protocol yet and we haven't really got into No. Back to that But at the the easy question, I'll let you start with the easy one before we do the harder one. Sure. They did ask if there's go bindings, and you did mention that community project. So Yes. Yeah. Yeah. Yeah. Oh, boy. I'm literally just gonna Google Iroh go. I'm so sorry. Actually, I'm gonna talk to that guy. Here it is. I believe this is the one. This is one, and then there's another one on I think we have it in our docs. Oh my gosh. Put me on

29:12 the spot. Languages. Have we added it yet? I don't know that we've added it yet. Oh my gosh. Oh, no. Yeah. Team's gonna kill me. I think we're but there's it's on GitLab. Let's yeah. I'm gonna have to pull it up in a second. Maybe I can pull it up while you're asking the next question. But, yes, there are gobunnings. There's a really lovely ah, you know what? Here. Give me one second here. Because there is actually in the ire of Discord, we just created a Go channel, so that person will be there. Yes. Oh my gosh. I apologize. So just

29:52 I wanna be good to this user because they are, you know No. Take your time. They're they are called bubbly hamster on on GitHub. That's a great name. Yes. Yeah. Was just looking at the there is an awesome Iroh,Rupo, but I don't see Yeah. We need to Yeah. And so this is yeah. This so here's the this is the relay setup for the Go. Oh my gosh. I will find it, and I will post it. I promise it exists. I'm sorry. We've been sort of just losing our minds as we've gotten one dot o at the door, like, three weeks

30:40 ago. But It's not a problem. I will make sure we get that link. I will add it to the resources on the Rawkode Academy webpage, and I'll leave a comment on the YouTube as well. So we will get that over to you. Not a problem whatsoever. And I appreciate it. Yeah. It's not get lab, it's gheti, which is a wee bit cooler because it's not Ruby. Yeah. Exactly. Here we go. Here's the IrohGroh bindings that I was referring to. I think these are the most sophisticated ones. I will get these added to the website. I will also paste this into chat just for others. I'm so sorry,

31:08 everybody. The first question. But yeah. But that was the easy one as well. Alright. Let's go to the hard question. Yeah. Let's go to the hard one. So the question was around a protocol. Yes. So you mentioned QUIC earlier. Yep. I'm sure there's also Iroh specific stuff going on. So maybe we could just go into that and how this works. Totally. So when we talk about trying to build a networking stack that functions, we really we do not number zero is really we think of ourselves more as a software carpentry shop, not as like a spec innovation lab. We do some of that stuff,

31:46 but like for the actual core of Iroh, it is I think we actually have the specs pulled together somewhere, do we? So, yeah, so the at the core of this, everything is based on QUIC. And so the core foundation of Iroh is IETF,RFC 9,000. And so this is the UDP based multiplex transport. Why this matters is this is this this protocol is approaching a decade old, and this is an effort what we love about QUIC is it's spiritually so aligned with what we're trying to do with Iroh. It is a software based effort to improve the ossification of the Internet. Not the web, the

32:31 Internet. Right? How how packets actually move through the tubes. And so Quick operates at the UDP layer, and there's you know, I'm not gonna go too deep into what Quick is, but the two things you really need to know are it is UDP, it it kinda does some funny business where it moves encryption lower in the stack. And so all of TLS actually is part of QUIC but at a different layer than TCP. Normally, you do TCP and then you do TLS on top. TLS is actually built into the QUIC stack, and there's really in inside of Iroh, there isn't such thing as an unencrypted connection. And

33:02 the last thing that you should know is QUIC has this thing called cheap streams. And so with QUIC, we are avoiding one of the core problems you run into with TCP streams, which is head of line blocking. I can paste a more bonkers example of this at some point. But, like, you can you can declare hundreds of streams, low thousands of streams. And that data, if you can imagine, like, again, going back to your classic web page request analogy, if you had a non HTTP version of a request, you can actually open a stream per resource, and those things would not block each other as they're coming

33:32 back. And that could be properly paced and congestion controlled inside of a congestion controller that's aware of those different streams. And you could do more interesting stuff on top of that, like the media over quick project actually adds priority to those streams. You could say, hey. I care about the audio more than the video. You can do really interesting stuff on top of this. And so the very center of the beating heart of Iroh is QUIC. We have, on top of that, added an implementation of multipath QUIC, which is the thing that took us fifteen months. We have our own QUIC implementation called NOC, which is number

34:00 zero QUIC for those who are playing for memes at home. But this the thing that this really why this took so long is the multipath spec basically is the same as TCP multipath before it. This is using this idea that you can you should be able to leverage multiple paths to the Internet for a single logical connection. And this is where we drive a lot of the magic for Iroh where you can say, hey, I'm on the Relay, and now I wanna move to I'm using the Relay to send traffic, and then I've just established a direct connection, and now I wanna use I p v four

34:31 and then I p v six. And we have add on top of that the idea of custom transports, And so you can then configure Iroh to say, actually, wanna use Bluetooth low energy. I wanna send data as with that as a viable path, or I wanna be able to use Wi Fi Aware and have that as a viable path for sending data for long range Wi Fi. And so those are the biggies. And then the last one actually is a quick NAT traversal. We we're not gonna talk maybe we'll get into NATs. You can decide. But NATs are standard for network address translation. This is how do

34:59 you actually get the connections to work across routers. This is actually more lore than it is spec, but we were the first ones to actually implement this draft, and one of our core engineers is heading to the IETF meeting in Austria in a couple of months to surface a bunch of the things we found as the first implementers of this. The upside of it is when Iroh is doing that traversal, it is all inside of the encrypted envelope. And so you're not actually broadcasting your IP addresses to public router boxes so that they don't actually see what that is doing. It's all inside of an encrypted quick

35:31 stream. And so that for us is a really important sort of foundation for getting all this right. But that's the lower level stuff. The last thing I will point to is that Quick uses this thing called an Alpin, which is a application level protocol name, and this is normally in the normal world, that's just HTTP. Right? And so that's the that is where you plug in, hey. I wanna speak HTTP three between each other. And so this is just a set of BICE that identifies the protocol that you wanna use. In Iroh, we treat that as a lovely place to plug in all kinds of stuff, and

36:02 so we actually support all of these different protocols like Iroh blobs for transferring data, and this will use a different ALPN and Iroh Gossip, which will use a different ALPN. This is for broadcasting messages. And so we see this as, like, this really exciting place where we can do very interesting stuff that kind of sits at the altitude below HTTP and above, you know, a really nice connection primitive. So there's lots of room to explore there. And but these we when you hear an Iroh protocol, we're talking about an Alpin on top of the quick stack. Alright. Just quick segue before I go back to

36:37 the original question. Is Iroh blobs, like, something which is can I can think of that as an alternative to IPFS? Very close. Yeah. It's missing one thing that IPFS has that this would need, which is global content discovery, the ability to put in any hash and then just, like, figure out bringing that hash. This thing, you basically need to say, hey. That peer, I wanna get this blob addressed by this hash, and it will do that for you. It also includes a whole bunch of magic for, like, I would like the following byte offset of that, and please verify those bytes as they come back,

37:06 and it can do a lot of wonderful magic. This is a very sophisticated protocol for data transfer. We're quite proud of it. It's it's the result of a lot of design work, but it relies heavily on the Blake three hashing algorithm for incremental verification reasons. We could, again, another rabbit hole I could spend two hours on. But yes, you can use it to transfer data. And actually, the SendMe project, if you do, the easiest one to look at is this. If you actually want to send a file between each other, this is all using our blobs under the hood. And so this uses send me is this

37:39 idea of just, like, can I just send you a file? If you wanna do one right now, we could totally But I think we we should do a send me, but first Okay. Because I think you've covered a lot. I move fast and sometimes I want technically. And I think if we can show an example, right, and we can work backwards, like, how the the tunnels are sending the data and then we can hopefully provide a bit more context there. However, there would be there is a couple of things. First, the person asked the question, sorry, y m o six one seven one. I'm not sure what

38:08 that username is, but was just happy it wasn't HTTP. So there you go. You hit you won the first sentence. Hey, there we go. I could've just I could've maybe I could've just said that it would've been shorter. They want to know whether Iroh is here to solve throughput problems, latency problems, or potentially both. Latency first, throughput second, ideally both. Alright. Quick is fundamentally meant for high latency context. That's it's it's that's where it really shines. If you have packet loss, if you have a high latency, quick is going to generally, that head of line blocking creates real problems. If

38:41 you're, like, waiting for specific packets to be acknowledged, that's what makes connecting your connections really jittery. And this cheap stream thing makes it possible for you to code it up so that it's not doing that. And so, yeah, it's definitely latency first. Throughput is coming. It is definitely, like, good, but QUIC is a younger protocol than TCP, And so you're you're gonna get a whole bunch of benefits in the Linux kernel and some other high performance areas where a TCP connection today will be a little bit faster than a quick connection with no latency. Nice. But all connections have some latency. So it's it's like kind of,

39:14 you know, this is where we get into the, like, hair splitting. Alright. I will put up their last question before we do the send me example. Please. Yeah. Yeah. Yeah. And I'm I'm to find Does this replace WireGuard and Tailscale, or would they run WireGuard and Tailscale along with Iroh? Yeah. I think we we had a moment on Hacker News where we did iroh1.o. And and I think this is honestly the, like, best person put it up best. People have described this as a programmable Tailscale. And, you know, and this tough comment was like, if you're new to Iroh, my mental model is roughly tail

39:48 scale at the application letter instead of the net network layer. And so, like, that's I think that's the right way to think about it. It's it's intended to be a programmable thing. It's it I I think of Talescale as this fantastic project where we're both trying to do the same thing. It's like trying to upgrade the way the Internet works. With Talescale, you get this lovely VPN looking shape to it. Our core contention is that, like, you know, when you're in a video streaming app, that's gonna have a very different networking condition than you would have for a browser. And so we really wanna give developers back

40:19 this programmability to be able say, oh, browser should work this way. My video app should work this way, and my somewhat video, somewhat chat, somewhat browser app is gonna need a little bit of all of them in the middle. So, yeah, hopefully that answers your question. Definitely does it's not like a replace, but it's it is it has a different purpose. It's intended to be used for programming. Alright. Let's now take all of this technical mumbo jumbo that you've been sharing with the world and show them a real application, and then let's work backwards and explain how all these parameters work. Totally. Totally.

40:52 Yeah. I mean, I just send me installed. Yes. So Okay. So let's let's start with, like, you know, localhost demos are are very uninteresting when you're claiming to be able to connect any two devices on the planet. So I'm gonna do send me, send. And so send me just to, like, you know, pull that page back up. The reason this is interesting is this is going to combine actually, we'll pull up source code because, like, we're here for, you know, we're here to look at some source code. What it's gonna do is we are going to it's one file. We intentionally try to make this a single

41:21 file. And it's it's a lot of imports. You know, it's Rust. It's gonna be I apologize. But the the language is what it is. It's very verbose. We what we're gonna do is when I type send me send, and I'm gonna give it you know, I think I have just like a cargo TOML file. So I apologize. It's like let's just cat this file so you can see it. It's not interesting. But if I do send me send, cargo dot toml. Oh, I have to do toml. Oh, I need to actually type the name of the file. Okay. And so when I type

41:54 this and hit this send, I'm now gonna hit copy. What you can see is oh, I actually can't this my terminal doesn't like this. I'm gonna copy paste this. It says, hey. Go run this other command somewhere else, anywhere else in the world. And you can see a few things here. This is that hash of the cargo dot toml file that I'm trying to send. And then this is a combination of the address to dial me at. This is my endpoint ID plus, hey, I want you to fetch the this hash, and we call this a ticket. So I'm gonna paste this to you, David. And hopefully,

42:27 you will actually be able to just punch that in. And if you do, it will directly connect our devices. And then Oh, yeah. We're doing NextOS stuff. I don't I don't I don't speak Next as well as you do, so you're gonna have to tell me if I'm doing it right. It's alright. It should be cached. I don't actually know why it fetched it again, but Alright. It's alright. And so you you very briefly saw on my terminal that I had a there was a thing that appeared that we were actually doing the transfer. And so we actually sent

43:00 some files between each other. Oh, you use bat. Oh, I'm so delighted by that. So so so, you know, you and I are across an ocean right now. Right? And and we our computers are we did there was no magic before that we set this up. Right? And this is kind of the, well, the magic is inside of Iroh, or maybe the magic is inside of all of us. But the the the purpose that I'm the thing that I'm trying to get at is, like, no special setup, any two devices anywhere on the planet. This works reliably. And this is the thing that we're super excited about.

43:30 And so I that sort of proves that the thing works. But we can actually kind of walk through some of this to understand, like, what is actually going on under the hood. And I think this is kind of helpful because SendMe is really nice in the sense that it has client and server roles built into it. But sometimes when we get into these, like, peer to peer things or Direct Connection shaped stuff, you feel like you need to just completely throw away everything you know about how networking works. And so that is not the case for send me. And so we had this thing instead

44:01 of send me. Had this, like, send me we have two options. Right? If we do send me help. You can see there's a send and receive. And when I'm doing send, I'm acting like a server. And when I'm doing receive, I'm acting like a client. And so when you were doing the receive command, I the send, as long as I have to leave it up, that process running for you to be able to connect to me. And so now you're I'm taking the role of a server. You're also taking the role of a client when you do the fetch itself. And so if we

44:28 pull this up, we can see this is gonna be a little bit kind of, like, gross because there's a lot of, like, code in here that is not directly relevant. And so instead, what I thought I would do is actually code up an example and start exchanging data between myself to show you just, like, a simple echo based version of this. Does that make sense as like a more useful starting point? Yeah. Or do you wanna ask questions about how SendMe works first before we move on to something a little more like toy example shaped? Well, yeah, I think we'll move on to the toy example. But

44:57 first, I think I am gonna try and explain how I think Send Me works so that you can tell me where I got it wrong. And hopefully that that helps. But Love my understanding is that when you run Send Me Send and you just provided a file. Right? Mhmm. This is speaking to the number zero idle relays and saying I am creating a new endpoint and Mhmm. I I actually don't know what it's like, I don't think it sends a file on it from there. Right? You're waiting for the client to to come in before you set the file. But you're saying create me an

45:28 endpoint and it's getting the key and then when you send me that blobby string thing that you sent me is that when I say I want to receive something, I'm going to again the numbers you know relays and saying I have this key, want to this device. And then it's communicating on the relays to find out where your server is and then it's just send I'm just going to that server and saying, okay, do you have a file for me? Mhmm. That is my very naive understanding of what we're doing right now. What I would also add is that SendMe doesn't have presets. At least

46:03 I'm assuming, well, actually, the semi code probably is Oh, yeah. Has a residual preset. Right? But could I just run SendMe and say, I wanna use different relays? Like, I'm curious. That. Yeah. Absolutely. So, like, I'm just literally gonna, like, search for preset. Actually, just n zero. Of course. Yeah. So there's this is deep inside of this. This is this is the send command, and we're building exactly as you said, building with the preset that's number zero. And you you just swap these. You literally just change that to anything else, and now it's using different relay servers. Right? And relay servers are identified by the URL. And

46:33 so you can you can actually even change them dynamically as you Well, that's what I was gonna say. Why do they have to be compile time? Like, they could be runtime. Right? They don't have to be. Nope. They can totally be runtime. And when you change them, Iroh will do something we call a net report under the hood, and that's that process is this whole I think I showed you this oh my gosh. Is that whole how this process of pinging relays is part of the net report. The other part is local networking conditions. And so when

47:05 you change the relay map, we call it, which is like the set of relays that you can possibly use, it'll just recalculate that and find a new home relay based on it. So, yeah, it doesn't need to be compile time. And actually, in the like, if you use this from JavaScript, it'll be totally runtime because it'll be provide it has to be provided at runtime. Nice. Yeah. And so, yeah, that's exactly right. I think a couple of things just to highlight from that that because I think we have this one we have this concept we call tickets, which we are basically just this mechanism. Where is the

47:37 source code for SendMe? Oh my gosh. I the time to me being confused by all of my browser tabs is for a land speed record this time. But in here Do know if we put a percentage sign into your Firefox tab bar, it searches for your tab. Right? Are you serious? Yeah. I thought I was the last Firefox user left, and so I didn't know that we had any No. I run Firefox lately. Alright. Oh, okay. Here we go. We'll use this concept. I'm gonna glaze over that and and just write it in the back of my head

48:12 to thing to remember for later. But this thing called a blob ticket is the thing that gets spit out. And so this string that we were pasting, this whole thing Actually, I'm I'm probably not supposed to do this, but I used to run this thing called ticket.iro.computer. See if it's still alive. Oh, and it still works. Standards are amazing. So this basically is just gonna decode this struct. And so what this is doing is just this is just like a basic c four encoder thing that's saying, hey. Here's the hash you're gonna form you're gonna fetch. This is actually interesting. This is saying

48:45 the format of this thing is actually something we call a hash sequence, which means it's a directory. And this is the same way that Git commits use a root to be able to name the files that they're hashing on the outside. And so the reason that your file came in and was labeled cargo.coml is we actually took the hash of the raw bytes, and then we wrapped that hash in with another piece of enclosing metadata that said, hey. The name of that file is cargo dot toml. And we've then wrapped those two things in a hash sequence, just those two hashes together, and that's the hash that

49:16 is here. And so this is basically the hash of, like, a directory in very serious air quotes. Then you have this we in one dot o, we renamed node ID to endpoint ID, but this is my actual endpoint ID from the time. And then this is the relay, and then these are some direct addresses. So it's actually published in your your public I p v four and your LAN I p v four as well so that I can decide which one to communicate with. It's like Yeah. And that's and that's actually that feels really counterintuitive and gross when most people look at it. And they're like, what?

49:48 Why on earth would you do that? There are actually numerous situations where if you don't publish that, it straight up won't work, and particularly in LAN situations, but also in virtual private networks. We run into lots of situations where if you're running inside of a VPN or virtual private cloud, sorry, VPCs. If you're in a situation where you, like, have, like, really isolated controlled networking conditions, actually, only addresses that will work are those local addresses. And so Do these kinda weird change the traffic path? Like, if we happen to have the same LAN, like, side of range. Right? Will it try and use that one nine two

50:22 one six eight eighty six first? And then go, oh, if that doesn't exist, and then go over the Internet. The prioritization is kind of like a heuristic space algorithms. Like, it's it the way that we choose those is kind of changes from release to release. We're always trying to make that selection as optimized as possible. Right? And so you can imagine that changes over time. This is the part that's more lower than spec. Like, the order that we dial them in, I'd have to dig into the code, but it changes over time. And there isn't, like, a known pattern. Like, oh, you should try

50:50 this address first because it will deterministically work faster or more reliably. And so we have to just kinda try everything out. This all happens in parallel. And so when that process is firing, your first bytes are actually being sent encrypted through the relay. The relay path we know exists. And so, generally, in our services, we see some we really care about something we call the direct data rate, which is how much data in the lifetime of a connection is actually sent directly between two endpoints and not to the relay. Right? We don't wanna use a relay if we can avoid it generally because that's the thing that

51:22 occurs egress, and then now we're just using servers. But the on average, what we usually see is the first packet flows to the relay. And by the time the first packet is finished flowing, we've started to negotiate direct, and the second packet will flow between the directly between the two devices because all that's happening in parallel. Right? So, like, that packet's flying through the air saying, hey. I wanna say, know, this is on the first bytes of the stream. We wanna really fast sign the first byte. And then in parallel, there's, like, this really fast negotiation happening where it's like, hey. Can we use this candidate? Can

51:49 we use you know, where can we figure out a way to connect directly? And so we have this really nice care we really want this characteristic where, like, it should feel like a normal HTTP connection. It should move fast, but it should also, as fast as possible, switch to being the lower latency connection. Lower latency assuming that you're actually physically closer than the relay server, but that's a whole another story. Alright. Yeah. Does that help answer things? Yeah. It's a lot. It did. It did. Yes. Okay. Cool. Yeah. And so, like, we use this ticket pattern a lot, and that ticket pattern is just

52:19 like it's just a struct that we encode to string. There's nothing really fancy about it. But nowadays, we often will just do the relay URL and leave off the direct addresses. That's also very normal, and you could do that. And Iroh will figure out why I just need to go talk to the Relay, and the Relay will give me a connection to that thing. This is one detail that is also probably worth covering. Endpoints just keep a literal WebSocket connection to their home relay, and that's how they get dialed in the first place. And so if you have an endpoint and you need to be able to

52:46 talk to it, we have this really, like, the longest, slowest ping trip we can possibly get to keep that connection alive where the relay can talk back to the endpoint and say, hey. This person wants to talk to you. And so that's where the that's how the connection is actually initiated. And that's why we only have one home relay. It's because we only wanna keep one WebSocket connection per endpoint. Alright. Yeah. Very cool. We got way off into the weeds on that one. That's awesome. But yeah. And so that's how SendMe works. You know, it's this blob protocol on top. And, like, you

53:18 can see a couple of other things in this code construction. This, like, this is the Alphans who are registering, hey, that we're gonna allow connections. Because this is the send side, we need to behave like a server. We can get into a little bit of this in example. But there's, yeah, there's more here that we can talk about. But that's those are the Alphans being registered. That's actually this is the use of the secret key that we talked about. So we have the builder, and then we say, hey. I wanna use this specific secret key so I can resurrect it over time if I need to. Yeah.

53:44 And then there's some other tricks that are this is, like, send me specific configuration. But Yeah. So, yeah, a couple of questions before we Yeah. We move on. That TechEd website you've got, can like, that does that TechEd only decodable for the lifetime of your send me command, or is it always decodable? The string is a string. Right? So we put all the information in that string. And so that yeah. That thing is this is a completely local process, this ticket.org computer. This is just happening in the And if I delete this character, oh, hey. That's valid. Yeah. I think it's just gonna be

54:22 valid. Yeah. Exactly. Yeah. There's this is literally just a signaling mechanism. Right? And so with SendMe, we don't have some central server. Normally, like, you shouldn't use this in a normal application. Right? The the the win of this is you don't need accounts. You don't need anything. You can just DM your friends this blob of GAC, and you can send files to each other for free, and they can be any size. But it comes at this cost of, like, there's no coordination server. Right? Normal applications would just hide all of this and would use servers to say, like, oh, this person's trying to connect to that person.

54:51 Right? And this endpoint ID is trying to connect to that endpoint ID. And this would all just happen as part of the application. We like tickets because it makes the examples really simple and can facilitate some of these, you know, more accountless forms. Okay. Got it. Thank you. Yeah. Yeah. Any other questions on the send me side before we move on to other bits? I can I'll try and get you another neck of the woods when we talk. No. I get it. Send me you just share a ticket. It's got that information. It allows me to initiate that connection, and then everything else happens

55:25 at the application there. So I I think I I understand what's going on there now. Has demystified the process. Okay. Oh, good. I'm glad. I hope it has for others. I'm just sitting here staring at Rust code in a browser. It's not not the most, like, straightforward thing in the world. But yeah. So I think one thing I wanted to show from for an example, like, were talking a little bit earlier about this, like, hey, can we set up an endpoint? This is the basics. Right? And so I figured what we do from here is we could go from this up and into echo

55:58 and building an echo server. And so where we just have a client and a server, and the anytime the client sends a request, it will just say whatever the message it is, the server will print the request and then send it back to the client exactly as it came back. And so you just just basically a demonstration of of that code move or of those bytes moving between those two devices. And that, I think, would be it's kind of, like, nice and instructive. But I have, like, two small problems with that. One, if it's just, like, totally a local host demo, it's really uninteresting. And

56:30 the second one is this machine that I'm currently talking to you on is, like, four years old, and it compiles Rust kind of slowly. And so I do it, and so I wanna show you how I actually, like, work on a day to day basis these days. We like many other folks who got really interested in local model execution as a company, we bought a Mac Studio. And we have this, like, new problem of, like, how do we that Mac Studio compiles way faster. And so I now actually spend all day SSH into that Mac Studio, which is sitting on the desk in my office, and I

57:02 use Iroh for that connection. So I thought it'd kind fun to, like, talk you through how that works, and it might be, like, a nice higher level example. So first, I'll actually just, like, set that up. What I can do here is I can do SSH v five at max studio. And this is just, like, very basic. Oh, what? Why is this not? Am I actually in the max? Am I in the Macs studio right now? Let's see. Sometimes, you know yeah. I think I did that whole session inside of the other computer. Yeah. Yeah. That was

57:36 actually all happening not on this device. Shoot. Okay. I'll log in. And so this is bog standard SSH, but now I am l s. This is and, like, the thing that's interesting is, like, this is an hour connection. Like, so every time I'm typing here, these are bytes being streamed back and forth between me and this computer that is a half a mile away for me right now. But I thought you said it was bog standard SSH. So it's bog standard SSH from the perspective that SSH supports this very interesting I'm not gonna show you my SSH config file, but it supports

58:11 this proxy command. And that proxy command is where all the magic happens. So it is bog standard SSH, but the proxy command is what allows you to say, dear SSH, I would like to you to use this following thing and map standard in and standard out to it and use that as the communication channel for for me to do secure socket handling communication. So you can do all your normal stuff, but we're gonna use this proxy command for the tunneling. And then what I've written is I haven't I don't actually we're gonna open source this in two weeks, but I'm just gonna show you the source code

58:39 now because it's not actually that secret. But the actual source here is all it is is a protocol. So it's another one of these ALPNs. We're calling this project pigeons because carrier pigeons finding their way home. It's kind of like the the shtick of this project. This will give me a protocol that will accept connections and then just map centered in and centered out using those regular endpoints. And so what I end up with is I have on the Mac Studio at my office, I have pigeons roost, which is like running the roost that they can

59:15 roost from. And then locally, I have pigeons fly and the endpoint ID of the Max Studio. And so now I'm typing through that. And what is interesting about this is, like, now I can you know, you can immediately see how you could just have a computer on your desk and you can talk to it from anywhere. But because it's bog standard SSH, I can use tooling that relies on normal SSH to talk to these remotely. And so I think I connect to SSH server, and we'll do this one. And then I have So to clarify, your proxy command in your SSH config has host

59:51 Mac Studio or whatever the the name was, and the proxy command is pigeons fly with a an arrow key. Yes. Let me So if you showed that, anyone could use that key to get to that issue. Now SSH still has usernames and passwords, and so you still need my username and password. But, yes, it's it you know, in Iroh land, public keys work like IP addresses. And so and and because those are dialable, this is why I'm not just, like, immediately showing it to you. So and so but I will here, let me do cat. I will censor it, and I'll I'll give you a just

1:00:26 so that it's not just so you can actually see it and it's not feeling very funky or weird. Give me one second here. Yeah. Okay. I have deleted, you know, some random characters and added some others. Okay. Great. Yeah. And so now this is what it looks like. And so this exactly and so this is this is part of my I also use that, and so I have this is closer to what it looks. Use a known host file and strictly host key checking. No. This is just configuration. But, like, we define the host, and then we have this proxy command.

1:01:02 And this proxy command is pigeons fly, use standard IO for your input and output, and then use this endpoint ID to talk to. And so that's it. Creating a tunnel and then SSH run right on top of it. Okay. And then we have this, like, lovely stream of bytes inside of pigeons, which is just, like, as fast as you possibly can. I had to write this, like, custom copy flush command because it needed it needs to work on not on eight kilobit boundaries, but instead as fast as you get bytes. But, yeah, this is just just using you know, each one of these is kind of turning

1:01:33 into encrypted quick packets and sending back and forth. And so it's just, like, really so for the rest of this demo, I'm actually I needed to explain this to you because I'm gonna use this Mac Studio on the right, which is actually a remote machine, and this one on the left, which is my local machine to talk to each other. And so now we can actually see connections that are real and and, like, instead of just being like localhost. And trust me, hand waving, I'm actually, you know, remotely dialing between the two. I hope that sort of, like, helps set up why this is. But I, like,

1:02:02 actually spend, like, 80 or 90% of my time SSH into this machine because it's just so much faster to compile. You'll see it in a second. But yeah. Does that make sense? It does. Yes. Thank you. And I think it's I think it's like a lovely trick. Like, SSH is just so well written that it supports this idea of proxying. Almost everything that you use for SSH proxying is using the same trick. But let's talk about some code. And so I'm gonna hide this for a second, and we'll I'm gonna paste in a giant block of code, and I'm gonna talk to you about it because I

1:02:31 think this is kind of easier than watching me type everything out all at once. But this is the echo example I wanna talk through. First, I'm gonna show it functioning so you can just sort of see what it is, and then we'll sort of talk through it. And so I'm gonna do cargo run. Actually, we're gonna go back to this one. We're gonna do cargo run server. So again, this is on the remote computer. And what this is gonna do is it's gonna print out an endpoint ID. And then over here, I'm gonna do cargo. I'm gonna set this over here and do cargo run client and

1:03:02 then this, and I'm gonna type Rawkode Live and run this. Cool. And so this is actually stuff running back and forth between the two. I can repeat this. And so this is just the two machines connecting, exchanging data. Things are happy. So when that process starts on the the bottom of the screen. So we're currently on the so sorry. A little cut off. Let me do this. I can just I'll I'll bring it back to normal size, and then we'll just deal with apologize. We learned earlier that my screen is a weird shape, and so we're we're kind of dealing with

1:03:35 this. I'll I'll run it one more time just so that you can sort of see it. And so this is the server on the right, the client on the left. And so we run this client, and this is compiling and running and sort of sending this message. As you can see, we got a message from a different endpoint ID. You'll notice that when I rerun this every time, the endpoint will change. And so this is now some other endpoint. And so that this when this start process is actually the process of Iroh starting, pinging those relay servers, picking a home relay, announcing itself, sending those messages, starting

1:04:04 the direct connection, sending the bytes, returning. Right? And and also a little bit of Rust compilation. Right? And so, like, that's the process is very fast even though it's doing a lot of things in networking land. And the amount of stuff you can do in a short time in networking land is very surprising. But, yeah, that's the high level. That's what's happening. And so we have a server role and a client role, and I'm hoping that this would be a chance to sort of go through what I love to call that there is no spoon moment because there's just one file in both cases. Right? I just

1:04:32 copy and pasted this single main RS. And what we're gonna do for this, and the reason that in the CLI, had to type, wanna be a server. I wanna be a client, is we're actually choosing that role. And this is the one thing that I think is worth really sort of this is if if I could say one thing to the world, you know, it's just the idea that client and server are just roles. And and if you have connectivity that work can work anywhere, you can swap them however you want. I could have the server be on the left and client be on the right either

1:04:59 way. And so this is you know, when we're used to thinking about, like, a traditional application, you know, you're a back end dev and you work entirely on the JSON APC, RPC API, and you work entirely on like, here's how I'm gonna restore this state. This is how the database is gonna hold it. And then the front end people work on like, oh, I'm gonna this is how I'm gonna consume that state. And and those code bases are meant to freely flex with each other. In this world, we have clients and servers, which is the same code base. It's a single file. Right? And so we have,

1:05:28 hey. You wanna be the server? Okay. Cool. Let's start the accept side. And so I'm gonna talk to you a little bit about the accept side. But the other side is, like, if you're a client, you're gonna say, hey. Where do you wanna dial? What message do you wanna send? And then we're gonna run the connect side of the server. Right? I probably should have renamed this to, like, client side for clarity. And then this should be renamed to start start server side. That might be a little less confusing. But, yeah, I wanna talk to you really briefly about the server side first because

1:05:57 I think this sort of shows the more complicated thing. This is our traditional back end where we're actually gonna accept requests, where things are gonna kinda work. Please interrupt me if there's any part of this that feels like I'm talking at warp speed. But jumping into this function definition below, we have a server side. And the server side code is relatively straightforward. We do that same bind thing we were talking about earlier, but now we're gonna use this thing we call a router. And a router is just literally split on the ALPN, which ALPN do you wanna talk to, and we're gonna map ALPNs to handlers.

1:06:30 And a handler is very similar to what you think of as an HTTP handler. In Iroh world, it looks like this. And so you have a function that you implement that accepts a connection. And now this is at this point, this connection is literally a quick connection. Right? And so this is where we get the whole quick API. All of the hole punching magic has happened somewhere else. It's not in this code base. But this is where you write all of if you wanna write a custom protocol, this is what it looks like. You have total control over accepting a bidirectional stream. And so

1:07:01 this is what it looks like to say, hey. I now have I now have to send thing. If I send bytes in here, that will go to the other side. If I receive in here, if I read from here, I'm gonna read from the other side. And now I get to design how this sort of communication pattern should interact. And so this is the server side of accepting bytes. The client side, we'll look at in a second. But all we're gonna do is allow the client to connect us, so we are accepting a bidirectional stream. We're gonna read to the end of that stream. We're gonna say,

1:07:28 hey. What do you wanna say to us? And that's gonna end up here. We're gonna do some Rust GAC where we convert these bytes into a string so we can print them out. We're gonna print that out, and then we're gonna echo it back. We're gonna write it back to the server, those exact bytes, and then we're gonna tell the client, hey, we're done, and we're gonna close the stream. And this concludes our request response protocol. And so we then take that, we wire it up to the router, and we give that router back as part of the return side of the setup function. In Rust parlance,

1:07:55 we have this whole concept of owned memory. So the the router actually owns the endpoint at this point. And so I can do, you know, router dot endpoint, and I can actually get it back out. But the endpoint is this thing that does all the networking. The router is the thing that is kind like, much we want you to think of this, like, very similar to, like, an HTTP router, where instead of doing URL path parameter endpoints, you're just doing these ALPNs. You don't have to use this, but I think it's a lot easier and more intuitive to think about. It's like, cool. I pick my ALPN.

1:08:22 I pick the thing that's gonna map to it, and then I'm gonna go from there. I'll pause there. Does that feel like a lot? This is the whole server implementation. But this is too much. So this kind of ALPN negotiation, I'm I'm trying to think of like a concrete example that would make sense for me. Right? But like Mhmm. Something I'm building open source is like an XMPP server. Right? So say I was doing that on Iroh and then someone came along and says, oh, we'd like matrix clients to work. Could I use this as like a a way to

1:08:57 multiplex and accept matrix connections or XMPP, but still all in a single self contained I think multiplex and protocols. Is that what Absolutely. Exactly. You've exactly got it. So we do accept, you know, XMPP, ALPN. You know, imagine someone has written an XMPP. Great. X and, like, you can put that in here, and then you'd have your, you know, XMPP handler. Is XMTP? Sorry. That's yeah. No. XMPP. Yeah. Yeah. Okay. Yeah. And so, like and you can do multiples of these. And there isn't this isn't very sophisticated. Like, you just either support the byte string that represents the APN or you don't.

1:09:35 And if you do, then it'll allow the connection. It'll map it. If we look if we dig into the the router code, it's like nothing. But it's like this 200 lines that just basically is a is a switch statement on, like in Rust, it's a match, but a match statement on the strings that are allowed, and that's it. And it just routes them. So it's cool. You don't have to use this. If you use it without, you can do you know, the version of this is just like endpoints.accept. And then you provide a function. I think you have to set it up in the builder. And then

1:10:04 you just literally can do full control over, like, every connection that comes in, you decide what happens, and maybe you wanna ignore the ALPN entirely. And you just wanna accept the connections and only do one thing. That's fine. But we think the router is, like, a nicer mechanism for the exact reason you just described where you wanna be able to support basically, like, different protocols and being able to compose them together. And so that's why we ship the router as part of the, like, core Iroh primitives. Okay. Got it. Nice. Yeah. So I think it's worth looking at the client side just to kind of, like,

1:10:32 show the other half because the client side is not gonna use a router. Right? And so client side is literally a client. It's gonna open this is where you actually see the connection initiated. And so this is where I'm gonna say, hey. I wanna connect to that address, and I wanna do it on this ALPN so that things match up. And then I'm gonna be the one that actually opens the bidirectional side. So this is the opening versus this down here, which is the accepting. And right? And these like, when you're designing a protocol, again, you do not have to design a protocol to use Iroh. Very

1:10:59 normal to just, like, use TCP tunneling as I showed you with pigeons or just, like, there's, like, a HTTP three implemented on top of Iroh, then you could just do normal HTTP semantics. What I think is fun is, like, if we're in total networking dork land, we might as well go all the way down to the bottom. And, like and so in this world, like, you actually have to design these things to kind of interlock where the client must open the connection. And this is kind of part of the protocol specification that is very light here, but this is saying implicitly all clients will open the connections,

1:11:26 and the server is waiting for those clients to open those that initial stream. You can actually do multiple streams. You could do let, you know, you send to equals con open BI. And this is completely not only is this on side, this is, like, expected. Right? And as, like, a pattern where now you have two streams, and you could do multiple things concurrently on those streams. And that's the whole idea of, like, cheap streams. You can have as many as you want. Here, we're only using one. We're gonna open it. We're gonna take the message that we got as the message that we're supposed to send. We're

1:11:57 gonna write that to the stream. We're gonna tell the server, hey, we're done. This stream is toast. All we wanted to send you was that thing. And then we're gonna read the response on the receive side, and then we're gonna print we're gonna use an assertion because I wanted to make sure that everything lined up, and then you're gonna close it. And you're gonna give a reason for closing. And it's like, hey. I wanna go away. This is a graceful shutdown. And then we're gonna shut down the entire endpoint because the client's done doing its job. The server does not have this client endpoint closed. Instead, we

1:12:24 do that We wait for control c. This is just like a Tokyo amorphism. Tokyo is the runtime that we are using in this case. You don't have to use it. But, yeah, we have control c here. We say it's like, hey. Just wait for the server to be shut down with a control c command on the terminal, and then we'll do a graceful shutdown of the router. And so that's where this is what will actually shut down the endpoint of the of the server. Yeah. And then that's the whole thing. Right? We were splitting on these two ideas and like, so, yes, we did go,

1:12:53 like, deeply into the weeds on, like, a protocol design. Right? This is, like, as low level as it gets. You have raw control over the streams. HTTP is gonna isn't you know, if you're used to, like, HTTP world, that's purely request response, and that's purely sort of a single set of bytes in and a single set of bytes out, and that's all you get is the sort of paintbrush you get to paint with. And that's totally fine. But where we didn't what we didn't sort of, like, add more complexity around is this idea of, like, a client and a server. You could still very much have those

1:13:20 roles. They can be very normal. And so you can you can sort of get some really interesting interactions and patterns here. You can imagine, like, I don't know if you've ever been in the place of designing an API where you're like in modern web development, it kind of feels like you're stuck with, like, either I have WebSocket or I have HTTP. Right? And so it's like, I'm either gonna do some, like, bidirectional thing and I can, like, have streams back and forth and I don't really reason about it, or I have to do single request response for specific resources. And in this world, you can, like, you

1:13:46 can go You can say, okay. I wanna stream five things in a row, and I wanna wait for all those to be acknowledged, and then we wanna finish that and then move to a phase that opens a sixth stream. Know, you do all kinds of stuff. And so this is kind of, like, where things get interesting and exciting. It's like, we we tend to write these protocols for folks. Most people that use Iroh don't write protocols by hand. Most of them just consume existing ones, HTTP, TCP tunneling. You know? But if you wanna get like I think it's worth knowing that this is there and waiting for

1:14:13 you as this, like, really, really, really interesting set of tools to work with if you wanna get super nitty gritty. Sweet. Yeah. Very cool. I think that's my rant. I'm going to go back to something you said right at the start because I don't think we've touched on it yet, but it definitely stuck in my head. And you mentioned something around, like, permissions or capabilities. Mhmm. I'm curious. How does this tie in? Is this something that I have to build in at the prod the protocol like LPN layer? Is it something that exists with, like, if I create an Iroh tunnel and someone

1:14:47 gets that endpoint, am I just open to that person or how does that permissions identity, how does this all work beyond just a key? A key. Yeah. So we it's yeah. I think your your intuition is exactly right. You if you were to write some, hey. I accept any request from anyone, and I publish my endpoint ID, you have not added authorization. Iroh isn't doing anything for you there. Instead, what we give you is the primitive to build authorization from. And so I we have a set of services called Iroh services, which is like all the hosted stuff on top. And the reason I bring

1:15:23 that up is because that's obviously an example of where permissions have to come into play and we have to do you know, you need to, like, be able to have permission to do certain things because it's a paid service. And so this, I think, is an example of not the only way to do it. With Iroh, we've intentionally kind of, like, left the authorization somewhat headless. Iroh blobs and all the protocols that we publish give you have this, like, place where you can hook in for authorization to basically say, okay. Here's the blobs protocol, but you can provide a function that will decide how auth should

1:15:55 work for you and your purposes. And we sew that into the protocols that we publish. Not everybody does. Right? Not everyone that writes in our protocol publishes it is required to do that. And so you do have to think about this. This is you know, we're giving you full programmatic control over everything. But to give you a sense of, like, what this looks like for a service that does have API secrets or something, We do a classic actually, let's do the RelayServer. This is a better example, where we have a whole bunch of this is an example of, like, here's an Iroh service

1:16:25 preset with a set of Relay URLs. This is how you could do custom Relay URLs that you will deploy for you. But we do full permissions on top of this. And what we do in this world is we use endpoint IDs as the foundation for the permissioning model. And so when you do a client builder with this preset and if you dig into this code, I can actually show that to you in a second, this is actually using the endpoint ID as the foundation of the permission structure, and it's and it's creating tokens that are delegating. Hey. This endpoint ID wants to perform the following action. Is

1:16:56 it allowed to? And so your the question you were asking, like, we kind of drop you off at the start of that conversation. We don't decide for you because, like, what we have found in talking with a bunch of developers, they're like, we really need OAuth. We really need JWT based authentication mechanisms. We really PGP. We want And we found when we started working on a networking imperative that the number of authorization opinions were quite disparate. And so we don't want to be declarative or we don't want you to force you into an authorization model. Like, HTTP doesn't have one. In HTTP, you just like you have

1:17:28 to provide bearer tokens and you have to decide how authorization works. And so we took the same stance with Iroh, but absolutely, you can strap authorization on top of this. And then I think that it the thing that I think is very valuable about it is because we're reusing TLS in this mutual format, once you've authorized an endpoint, every single packet you are receiving is affirming possession of that private key that is the root of the trust of that conversation. And for us, that's a really exciting primitive to use. Right? Just by virtue of receiving packets in this giant endpoint. You know? Here, I

1:18:00 know that I'm always talking to this endpoint ID and that every byte of data it has sent me is encrypted with a private key that represents the other half of that. And so when I assign permissions to that endpoint ID, it is being affirmed at all times. And so we kinda get this nice duality of, like, authorization and connectivity in the same primitive. We don't you know? But to answer your question directly, we don't tell you how to do auth, and we don't we don't provide that for you. And we intentionally we've and we've kind of intentionally made that decision. We'll have more opinions on how that

1:18:30 works and, like, more declarative, like, framework y, looking easier to adopt versions of this over time. But at first, we wanted to get the networking right. So does that answer your question? It's a little bit like womp womp because we don't have the, here, just download this great. But, like, that's the honest answer. It does. I guess I think the question in my head now and also it comes it's very similar to maybe something from the audience. So let me start with the audience. Y m o asked if the server can get, the client IP or the client IP ever sees the server IPs. At the same

1:19:04 time, I would actually go a little bit further with that question. It's like, when I run a server, there's an ephemeral key that says I can have this endpoint, right, on the the relay network. Is that key available to clients that connect? And do the clients get an ephemeral key for that? Because it's they both have keys, right, when they communicate. So do I have access to know the public key of the client as well? Like, how much information is available to the client server? Yeah. And so when to so just to be really specific about the because there's three entities in this conversation. Right?

1:19:38 There's endpoint a, endpoint b, and the relay. And so when you say server, do you mean the relay, or do you mean the server that I've been describing here? I meant the server that that you're running, the send me server. The send me server. So the send me whenever an endpoint receives a connection, you under the hood, the if we do actually, we don't even need to go in under the hood. We do connection. Adder no. Let's do where can we do this? Where can I show you? Yeah. Actually, I think it should be connection remote. That's just the remote ID. I

1:20:11 think we intentionally hide a lot of this from you. Well, that remote ID was a public key. Right? That is a public key. Yes. And so this is the public key that is connecting to you. And so you know the key that's connected to you. And the key the connect the key initiating the connection, the client, knows the public key of the server. During the process of the connection, the two absolutely discover each other's IP addresses. And so that's we and so they that is part of this exchange that's happening. So let me do docs. You know, this what is

1:20:46 Iroh? This GIF, think. GIF, GIF, GIF. You decide. This is how the hole punching works. And so these we are absolutely pulling up, hey, what Relay are you connected to? And they are acquiring this knowledge. Right? So this is starting the animation from the beginning. We say, hey, Relay, I want to do this. These are two address candidates addresses, and this is interactive connectivity establishment. This is not actually ICE, but this is our NAT traversal stuff. But this is how we're actually doing the reach out. But you can see that they're trying to figure out how to connect to each other,

1:21:17 and they are disclosing information to each other. And when it actually maps and you get a connection, at this point, Alice and Bob know each other's IP addresses. And so they they are that's inside of the information there that is that is provided to each endpoint. It's buried in the API since, like, we don't necessarily, like, expose it, but it's there. Right? Like, that's you can obviously write a client that would expose that information. Not obviously. That is possible. I don't know if that answers your question, but, like so you always know you always, always, always know endpoint IDs. You know the public side. You never know

1:21:47 and you never know the private side. You're not supposed to ever move the private key. That's what that's the foundation of the security model. The IP addresses are disclosed. That is part of what we're trying to get direct connections. Like, you and I are on a video call right now. Our machines know each other's IP addresses. Right? Like, we that's how we're establishing a really fast, slow latency connection that is affordable for the person running the service. And so this isn't, like, some magic that, like, we're doing that is totally different from live connection practices that are modern. There are projects out there that are using Iroh

1:22:16 in a relay only mode where the relay basically all traffic moves only between the relay. And in that world, the relay can actually do IP of address obfuscation, where you can say, we we actually just only ever wanna talk to the relay. And because we only ever talk to the relay, the relay will not actually disclose the IP address of of Bob to Alice or vice versa. And so it is a stronger model, but it in terms of the security characteristics, they never learn each other's IP addresses. But you lose all your direct connect direct connectivity as a as a trade off. And so now you are

1:22:47 in a much more classic server pattern. Got it. Alright. I think we and eventually answered why it was other question as well, which came a little bit earlier in the session. But they were just asking about whether they could use us for signaling to connect WebRTC audio video connections, which it sounds like that would be the perfect Yes. And it's like yeah. And and yeah. I mean, I I will say that Iroh is about thirty years younger than WebRTC at this point. So, like, I in my experience, it's about twice as quick in terms of, like, I've seen video calls

1:23:23 that, like, the video on Iroh lands a second faster than the WebRTC connection because of all this head of line blocking stuff that this engineering that's come from Google and a bunch of other folks. But, yes, you could absolutely use it for that. And and I wouldn't be offended. You should totally use WebRTC if that's what you wanna use. Well, there's also media over quick, which is something I've been keeping my eye on because it's a very good way to do that low latency real time streaming, which I think is pretty cool. Pixelated. Yeah. This is this is lovely stuff. Yeah. And I think I completely agree.

1:23:56 There's, like, a lot of magic happening here. This is, like, really exciting because media over quick is pull based, and this is where it yeah. Now what pull based means is, like, you have to go and tell it, hey. I want you to start streaming video, which is what makes that just mix perfectly with Iroh because now you can dial from cloud to edge. Right? And so now you can sit in your server or sit on your phone and reach out to that camera and say, I want you to start streaming video. Right? And that capacity is the sort of last mile magic that Iroh brings that

1:24:26 matches so well with Media Over Quick, where Media Over Quick is inherently more efficient because during that session creation, you're just, like, not creating video streams that nobody's asking for. But you still need this. Because it's pull based, you have to find some way to start pulling, and Iroh really pairs well with that. Awesome. Alright. Is there anything else you want to share before I move this back over to big face mode to No. Let's go. Let's yeah. I've I think I've talked us into a million directions, so I'm happy to chill here. Well, yeah. We are now almost ninety

1:24:58 minutes into the session and, you know, I feel like we're showing a lot, but also there's so much more we could go into. It goes forever. It's it's just Yeah. One of the things I really loved when I was starting to explore the project was there is the Iroh examples github repository. So I'll make sure that link is available in the discussion for but it's a good way just to see how to get started on what's possible as well, which I thought was really nice. As well as the awesome Iroh repository too, which is showing what other people are building on top of Iroh. So, yeah. I

1:25:30 don't think there's ever gonna be a shortage of ideas of the things that you can do Especially now with AI robots that can just ship so much code to like, I've got a stupid idea. Like, go, cloud. Go. I think that's to me, that's the part that's the most exciting is like, we now with this primitive, like, can ship an app that is just so much more self contained. And so those ideas, like, you know, I think you run into this thing in the AI world where like, oh, and now I need to keep a server running and all this stuff. And like, with Iroh, it's

1:25:58 just like, oh, cool. No. I can just ship client code that will just be able to connect to other clients. And and I don't need to keep servers running. I can just like use the number zero preset. No infrastructure required, and then I can sort of like let that exist. And one of my like, some of our folks have we'll take this to its natural conclusion and compile Iroh to Wasm, and then then it just becomes this browser thing. And then and then now we could just have established connections directly between each other, and it's delivered as a JS deliverable on a web page and this is

1:26:27 like, lovely. Oh, yeah. That's possible. Yeah. I I think I've mentioned this to you before when we were discussing during this session is that I've been building my own studio for livestreams because one of my dreams at some point is to have the ability where anyone in audience can just jump in and ask a question. Like, you know, like a Google Meet, but without going through Google's servers, without going through you without going to YouTube. I I want to be able to own this whole experience and make it more interactive and real time. And I think Iroh is one of those missing components that I've just like

1:26:59 now it's filling it's answering the questions I didn't know how to answer yet, which is really Oh, that's so exciting. I I wanna work on that with you. So we need Iroh, media over quick. We need our own LPN for the, you know, all the different Let's go all the way. Let's do like custom hardware with like a video, you know, oh, caller 27, you know, and like but yeah. But, yeah. I mean, when you have these primitives, these things become, you know, they're they're not anymore. They're things that I can build and it just comes down to prioritization and get my AI robots to help me

1:27:31 put that together. So Absolutely. I think lots of cool things are gonna happen with Rawkode Studio over the next couple of weeks. So So cool. Well, keep me informed. I will I will pay attention. But I will. My my plan is to do more of it in public. Everything I've been building has been very private. But yeah. I enjoy livestreaming. I need to start doing more of my own stuff here. But I also just love sitting down having conversations with people that are building all these really cool things. Like, this has been a fascinating session for me, so thank you so much for I'm glad. Taking the

1:28:00 time. I hope I didn't talk it a mile a minute. I I'm I'm guilty of that at times, but I I am very excited. But and thank you for having us on. It was really, you know, me on, but, like, I as as a representative of the project. Yeah. I really appreciate the time. Well, yeah. And I'll just be selfish and say, I'm make sure I'm make sure that there's another session where we do something. I've got some ideas for things we can build. So Oh, amazing. Yeah. Can we we can can we switch? And I'll I'll ask you questions about how what you built. Like Yeah.

1:28:28 Yeah. For for sure. For sure. Cool. Alright. YMO, thank you for all your questions. YMO is also thanking us for an amazing session. You're far too kind, but we really appreciate you waiting. Yes. Alright. Thank you so much. Any last words? No. That's great. Thanks for having me. Alright. Alright. Get off then. No. Okay. I have one more minute of AI music for you to see this. Thank you again for your time. Thank you to everyone for watching. I will see you all next time. The network alive.