On this page On this page
episode 16 — WebRTC and Sans IO with Martin Algesten.
We sit down with Rust developer Martin Algesten for a deep dive into WebRTC and the Sans IO approach to protocol design. Martin traces the surprising origins of WebRTC, explains why real time media over UDP is both powerful and painfully complex, and walks through how peer to peer connections work under the hood. The conversation then shifts to Sans IO design, why it matters for clean protocol implementations in Rust, and how Martin applies it in his own WebRTC stack, str0m.
If you like this podcast you might also like our modular network framework in Rust: https://ramaproxy.org
00:00 Intro00:40 Get to know Martin Algensten06:16 A bit of WebRTC history09:38 WebRTC 10130:05 P2P and Stun36:00 WebRTC: stages and flow from start to finish45:43 How Martin got into WebRTC and started the str0m project52:36 What is Sans IO?01:06:36 Why DTLS is not Sans IO in Str0m, but Str0m is01:18:34 Outro
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj
Elizabeth (Plabayo)
0:14 | 🔗
This is netstack.fm, your weekly podcast about networking, Rust, and everything in between. You are listening to episode 16, recorded on the 19th of November, 2025, where Glen has a conversation with Martin Algensten about the Sans IO approach to protocol design and how it shapes real-world network implementations in Hello everybody. Welcome for another week of Netstack.FM Today with me, my guest is Martin Algensten, but I'm going to give him the word later so he can correct me. I'm sure I mispronounced his name. All right. So today we're going to talk about two topics and also an example of the latter one. We're going to talk a bit about the WebRTC, what it is, why it's used, how it is today being used, et cetera. And we will also talk about Sans IO which is a topic close to my heart. That's great. It's great. It doesn't just apply to networking, but I have a feeling in networking it can play a much bigger role than it is today. And then he will also explain us like a practical example of Sans IO in the wild. So welcome, Martin. Yeah, thank you. ⁓ Your pronunciation of my surname is fine. I've heard much worse. So Martin Algesten, or, you know, I'm from Sweden, so it's Martin Algesten in Swedish. But yeah, I'm from Sweden. I live in Barcelona now because I don't agree with the Swedish weather. ⁓ And yeah, I sort of ⁓ love Rust and I am maintaining a couple of Rust libraries. And we're going to talk about some of those today. *laughing* Yes, I'm very excited for that. yeah, before we of course dive into technicalities, Martin, I would say let's maybe hear a bit about your background, how you got into this kind of topic, into programming in general, and of course also how you got as a Swede in Barcelona. ⁓ Sure, yeah, so I'm from Sweden from a small town called Arvika which is closer to Oslo than it is to Stockholm but still on the Swedish side. ⁓ when I grew up there I was going to be a marine biologist but ⁓ then my cousins bought a computer and I became obsessed. And so my first computer was like a Commodore 64. And that was then followed by Amiga 500. And that was like the starting point for everything that followed. ⁓ I went for university. I went up to North Sweden to Luleå, which is Luleå University of Technology. That was like in the mid 90s. And interestingly, there is like some overlap here with what we're going to talk about later. some of these streaming technologies and the things that sort of became WebRTC is actually had its roots in that university and was like spin-offs from that university. So I encountered some of these things when I was there, but I didn't realize that this was, I wasn't involved in it at all. And I was only on the sidelines sort of playing a little bit with the technology because we had like a 10 megabit LAN there, which was like, you know, the first time as a as an Amiga 500 user, you're coming to a place where there's like a LAN and you could sort of play with these streaming technologies on the network. And that's, so I kind of encountered some of this back then. And then my professional career after university sort of went via Java, Node.js to finally sort of land in Rust. I guess I was always sort of quite close to hardware. thinking because when the Amiga 500 I did play with assembly and kind of toy with those things and I always kind of even if I was programming in higher level languages like Java and Node.js or whatever I kind of never lost touch with what's going on underneath and Rust was the first time I felt like this is like where I really love it because I never quite liked C and the kind of thorny kind of situation you get into there. yeah, once I discovered Ross, there was no no going back. That's what I want to do now. Yeah, I have feeling ⁓ a lot of us find ourselves in that place. Like personally, I always... It's like a double-edged sword, not double-edged sword, but like, at one hand, I really find a language like C very charming, like it's very easy to understand and it feels good to program in it. But then once you get to a certain scale, I feel it's almost impossible to avoid, at least for me, and especially when you work in teams, find to avoid bugs and all kinds of assumptions you might make. And then, the other thing I really don't like is that in most languages, and not just to C, is that you cannot really... refactor and code usually doesn't age very well and you get new ideas and like your needs grow, your requirements change and so it's very nice that a language like Rust allows you to refactor all the time which is something that like let especially when a codebase in C or Go or Python or any of these gets to a certain size usually you get pretty scared to like touch it at least in that kind of scale ⁓ Mm. right. also like how I can use one language to both be ⁓ doing the stuff like WebRTC, but I've also been dabbling in embedded stuff and working with raw hardware. I can use the same language in both places and it's fine. It compiles down to something which is pretty much as good as if I've done it in sort of hand-rolled C or whatever. So yeah, I love that. Yeah, very cool. Okay. So you mentioned something very interesting and then I think from there we can slowly transition towards WebRTC is that you said at university there were some origins or beginnings of what nowadays is WebRTC. So maybe before we dive into WebRTC you can maybe tell a bit more about that. Yeah, so a lot of the technologies that WebRTC is built upon are basically technologies that stems from the early and mid and late 90s. It's all 90s technologies, essentially. And this was intermingled with streaming videos that have grew out during this time in the 90s. This is when we started having, you know, the internet and interconnected networks that were fast enough to actually carry both audio and video. And one company that was deeply involved in this in the 90s was a company called Maratec, which was founded in Luleå and was kind of a spin-off of that university where I went. And the people that sort of founded that company, were sort of around, they were a couple of years older, sort of ahead of me in terms of, so I knew about them more and sort of... and played with the tech that they've created, course, some of it. And this company was later bought by Google in 2007. So these people went on to Google and ⁓ eventually that kind of transitioned into WebRTC in 2010s. back then you sort of had these universities, there were other universities involved as well. And you also had big companies like Ericsson in Sweden, know, with Telephony ⁓ and Cisco. They were also involved in the kind of formation of the underlying protocols for a lot of the stuff that is WebRTC today. So there's connections to IP, Telephony and these kind of conference systems that these companies were more kind of focusing on back then. Obviously today when we say WebRTC, we're talking about conferencing in a browser and transmitting video and audio, but like, you know, we are doing right now in this podcast session here. ⁓ But yeah, this also that was intermingled with IP telephony and the protocols are shared. A lot of them are shared in various applications. Okay, and so as far as I know, WebRTC stands for Web Real-Time Communication. I mean, yeah. So, and... I feel it's one of those protocols which is the least well known from people developing within like application and browsers. Of course, it's not limited to browsers. You can also use WebRTC outside browse and it is used. But it is also possible to use from within a browser from the application layer. And I feel unless you are in a very specific kind of work, you usually don't touch it, which is very different than something like most people will at least know of things like the fetch API. So maybe we can start to unpack a bit what is WebRTC exactly? What is it built upon? How it works? What it tries to solve? WebRTC is a W3C standard and it encapsulates a whole bunch of underlying protocols. It's a weird standard to get your head around and maybe this is part of why less people are inclined to engage with it. If you compare, if you take Other standards like HTTP 1.1. obviously write another thing called UREC, is another library for like request or whatever. If you take a spec like that RFC, that is the HTTP 1.1 spec, you can read that spec and you can go through it and you can get a good understanding of what you need to do to implement a rudimentary HTTP client or server. And you don't need to like look at much else. But if you look at the WebRTC standard that is on the W3C pages, it's nothing like that. It reads a bit like it's an algorithm description, like assign this name to this slot and then do this and then do this. So it's like, it's almost like reading Sodo code or something like that. And I think it's almost like they've taken their C++ implementation, is called Live WebRTC, which is Chrome's, Google's original implementation. And sort of almost translated that into more kind of words rather than... So it's a very weird spec to get your head around. And when you start there, you're just looking at them like, what am I even going to do with this? And to actually get to what you need to understand... There's like a whole bunch of RFCs that you need to look at. I bet if you were to like try really dive into this, you would end up with 10 plus browser tabs, all pointing to different RFCs and they're all interconnected in ways that are surprising and not always clear. ⁓ And this is maybe, it is the nature of it, I guess. I have a love-hate relationship to WebRTC. Maybe I should preface by saying that I'm not, I don't just love it. I think it's also complicated and not so good. it's, it's, you always get the feeling is does it really have to be this complex to do just transfer video from or audio from one place to the other. And the answer is probably no, it doesn't. But we had all these specs, all these different standards. that were sort of developed partly for this purpose, but not entirely for this purpose. And we reused them into WebRTC. And that's why you end up in the situation that we're in. And all of these protocols, all of these specs, all these things were developed, as I said, in the nineties. So it's different times. It's like much more open times. We didn't have to worry so much about encryption and DDoS attacks and the rest of it. You know, and a lot of it was thinking about stuff like multicast. I mean, like multicasting video is not something that we at all think much about today. I mean, if it's used anywhere, I don't know. it's, it's kind of protocols made for a different time. And it really, you can really tell by reading these specifications, because also you can really tell it's written for, ⁓ constrained environments like CPU constraint and bandwidth constraints and, memory. So you need to be careful about how you use that, which was the case back then. And now we can afford ourselves to be a little bit more kind of free with that. And this is very, very different when you read the specs compared to something like Quic, which was, you know, developed very late and it's a very similar thing where you're using UDP to almost stream something. You can use Quic for media as well. And Quic is like then immediately sort of start with encryption. That's like the the beginning and then you build on top of that and that's not at all where these protocols are. Yeah, and of course it has its advantages and disadvantages. Like sometimes people, I would say, with very good reason say like, not everything should be encrypted. Like let's say it's something very internal and so I'm forcing it. Of course, nothing stops you from running Quic with all TLS and most implementations do support it, be it not in browsers, but like if you use outside browsers. But okay, so to dive a bit deeper. ⁓ Let's say, so when I think about HTTP, most people know at least, okay, it isn't there because I wanna make a request to a server and I get a response. Fundamentally, what is WebRTC for? We already know it's complicated, we know it has certain reasons why, cetera, but fundamentally, what is it used for? Right. So we use it for transporting media, video and audio between two peers. And there is a third kind of thing that is there as well, which is a little bit like WebSockets. There's something called data channels, which sort of, can transfer data with it as well. And it's actually one of the most surprising use cases is in crypto trading, it's actually used quite a bit because it's got the UDP low latency kind of thing, which, which Web sockets are TCP. So I guess we should just maybe talk about the fundamentals of like low latency streaming video, what you need to do to just get that going. And then we can move into how that works in WebRTC. So if you were to build something like RTP for yourself, which is like the real time protocol for streaming media, then you would choose UDP because TCP here is not a good choice because it would You will get that head of line blocking problem, is what QUIC is also solving. Like TCP will guarantee delivery and if you lose any packets when you're transferring, then it will do resense until it got all the data across. This is not useful when you are transferring audio and video, maybe a little bit, but not so much. Because if you drop an audio packet, if you drop a single encoded piece of audio, it's probably not even going to notice if it's just one. And I mean, when you start dropping more packets, sure, eventually it's going to start glitching, but you can drop quite a lot before it gets like unintelligible, you can't hear it. So we used UDP to get the low latency because real time is the key here. We really want to talk in real time with each other. And then when we transfer video, there is a couple of more constraints. Audio is very, very simple because it's just one packet and then you can interpret that straight away. Video is a little bit more complicated because all video encoding, as far as I know, is like it builds on the idea of having a key frame and then you would have follow up packets which basically builds on that key frame. So it's like an incremental state. You start with here is the entire frame, the entire video frame that we have now. And then you kind of transmits deltas. You say, okay, so this part's moving, this part's moving, this part's moving. And this is all the different encodings like VP8, H264 and so on. They do that. So when you transfer this with UDP, you need to transfer then keyframes with UDP and say, okay, here comes the big one. And also remember with UDP, we need to stay under the MTU, the max transmission unit, because otherwise the packet is probably just going to be dropped by some link on the way, because UDP is by nature, if you can't handle it, you just throw it away. That's the point of UDP kind of thing. So, ⁓ You need to stay under the MTU. You need to chunk up this key frame. You send it through probably over a couple of packets and then you send like the Delta packets off to that. So you need a bi-directional communication here. You need to send, the sender needs to send these things and then the receiver needs to say, ⁓ wait, that packet, I'm missing that. I need to get a recent. And the other thing is the sender probably, or receiver probably needs to also say, I need a key frame. Because imagine if you join a conference call, join a current someone is currently sending. You don't want to like wait for many seconds until the next key frame. need to be able to say, give me a key frame now. I want it right now. So this kind of bidirectionality is always there when you're talking about something like RTP, you have media flowing in one direction and then some feedback in the other direction, which is like, I'm missing these packets. I want a key frame. And the third one is probably like. Here are some bandwidth estimation gubbins that you can use to reduce the quality of the video, whatever, if it's going too fast. That's the fundamental of building a streaming stream. so no matter if you're talking RTP, which is using WebRTC or there are other protocols for this as well. Like there is something called Media Over Quick now, which is like the new way of doing this in, in the world of Quic. And all of these, they use this fundamental. This is the starting point for streaming media. And then I guess when we talk about WebRTC to bring it back to that again, WebRTC has like, it's this transfer of audio video, like we just described. And then there is net hole punching. So when we're talking about firewalls and we're talking about peer to peer communication, then We want people to be able to send videos straight to each other, not going via a server. We want to go directly. And that requires something to sort out the idea of firewalls that are in between. And then the third part is these data channels where you can just use it as a web socket effectively. So those are the three areas I would say, which is like WebRTC. And we can go into the protocols then to explore how this is working from the ground up. Yep. Okay, so so far we've learned that it's built on top of UDP, but that doesn't mean because like sometimes we can drop packets, but sometimes we do require something even if it wasn't received, we need to ask to get it back. So that means like something what TCP solves for us, we kind of have to do ourselves now. And that's probably what the mapRTC is. We also know that it is often used for streaming video and audio, where audio is simple, but like with video is more complicated because because you were there with Delta. So we do have those kind of constraints where we sometimes need data, even if we're missing it, we need to request it again. ⁓ Now, what I wonder is, let's say I'm in a video call with a group of people and you were mentioning that you also want like peer to peer communication. Does that mean that everybody is having channels with everybody else or like how does that work? So the WebRTC designed for enabling peer-to-peer communication. ⁓ if we think that that's like, that's one use case. And then what many do, if you like in a Zoom call and maybe what we're doing here today, I don't know exactly how Riverside works, but basically ⁓ there is something where you have a server involved as well. So everyone is talking to the server and the server is forwarding. these packets to everyone else that is involved in that call. And you call that function, ⁓ SFU, which is a forwarding unit. So, the, this is also how you scale it up probably, because if we take, if we, if we were to say peer to peer, so we would like, say we were doing pure peer to peer. So I'm sending my data to you and then we invite person number three. Now I need to send to both of you guys because we sort of building a little network between us here. And we do number four. Then you see that these kinds of streams that you need to send are effectively growing ⁓ with, with exponentially between us. So the bandwidth wise, can start to get quite crowded when you start doing it. Like everyone has to send everyone. And also it can become a bit rickety because you could have two people that maybe can't punch a firewall hole between themselves. and two others that can, so you can get these weird asymmetries where you basically don't, you can't use it like that. But peer-to-peer, pure peer-to-peer conferencing, ⁓ there used to be some of those solutions around that you could just use because it doesn't cost any bandwidth for the one providing it because you're just talking straight to the person that you're gonna talk to. ⁓ Those... will scale probably up to like seven, eight people quite easily. And if you go beyond that, you will start struggling. So when you have conference calls that go larger than that, you probably have a server involved and that is acting as one of the peers. But of course you also have this kind of like hybrid modes where it it kind of looks like peer-to-peer But you basically elect like people like like Usually you have in one let's say you have a call with eight people You might have one or two people whose machine and with bandwidth is very high bandwidth and can really kind of like act like a server So like on the fly you would elect them as basically be a server and they would relay most of the packets And then it like some algorithms or some protocols allow them to like switch the server on the fly so you never have like an actual server but usually one or two peers or acting like a server where i've seen this in play is from my background in the game industry where sometimes you have peers to peer game servers and then you just elect one of them as the server on the fly and then sometimes you see like a little i don't know glitch because suddenly the server like switched like it's not someone else ⁓ so that's one way to solve it i guess Yeah, I mean, I have personally never been involved in that situation, but I could see that working as well. ⁓ You probably, depending on whether you are using applications or a browser, you might also encounter some things here because if you are, ⁓ a browser doesn't really allow you to work on the RTP level. There are some work being done in that area right now, but basically if you say you want to just like forward RTP packets between various peers, the browser doesn't let you do that straight up. need to actually, the browser will take you up to a media stream or effectively reconstitute the H.264 or the VP8 or whatever you have. ⁓ And you could then like forward that to another one. ⁓ It's all going via JavaScript as well. So maybe that's also a bit of a constraint here that... ⁓ It's single threaded and it might not be the most efficient way of forwarding data between people. Yeah, and then so, yeah, WebRTC, I would think, even though it's not required, this is most commonly used in the context of a browser, but a browser doesn't allow you to open UDP sockets. So I assume there is like some kind of web API specifically for WebRTC, or is there an API that is being piggybacked on by WebRTC? So everything is abstracted into something called ⁓ RTC peer connection. And there are excellent docs on Mozilla about that, which is part of, the JavaScript API, you find RTC peer connection. And it's in high level abstraction of how you configure one of these sessions. And that in turn eventually sort of trickles down to the UDP level. And with RTC peer connection, if you were to want to to use this as an alternative to WebSockets, you start with RTC peer connection and you say that you want to create a data channel in that. And that will then lead you down the path of what you need to configure in order to make that work. And you can make that work between two browsers, for instance, to have a WebSocket connection, not WebSocket, data channel connection between them, but it appears as if it is a WebSocket where you have. You know, on the JavaScript side, have just something where you can write, say a string or some binary data into, and then you have a callback where you receive the data out. Okay, but at the same time, WebRTC is meant to solve very particular problems also related to the video and audio data, but specifically video data. Does that mean that that high level API also helps with that? Yes, so when you want to send a camera or a microphone, there are some APIs where you can request the browser to provide you with the camera stream or the microphone stream. So you request those streams and then you take those streams and you plug them into the RTC peer connection in certain places where you say, OK, add this track that I have over here. And that means you're not actually sort of taking the every single H.264 kind of packet and forwarding it in JavaScript. This happens on a lower level. So this is a high level abstraction that just connects the browser's kind of camera input with your RTC peer connection output. And then it sort of just magically fixes everything underneath that all the way down to the UDP layer where it's being transmitted over the web. Okay, that's a very nice experience and as you said it's a high level abstraction which means you're for each of these purposes, each of these tracks, each of these different media you're like opening a stream or a connection but that probably means that in reality it's all going over a single UDP socket I imagine. Yes, so, but all these protocols that we're talking about that goes with UDP here, they are multiplexed over a single port. So we're talking about three protocols. It's STUN, which is it's using for traversal NATs. I can't remember name. it's It's tools for transversing NAT and punching these holes in the firewalls. That's what STUN is for. There is ⁓ RTP or rather SRTP because it is encrypted and the S in SRTP is for secure. And then there is DTLS, which is with these data channels and the acts like web sockets. Those three protocols can actually live on the same UDP socket because you can just look at the first couple of bytes and know whether it's one of the three, so you can actually reuse the same UDP socket for all three. Okay, and DTLS stands for, I imagine, datagram TLS, meaning like TLS for UDP or... Yeah, that's right. So we have, if we look at the kind of stack of things we have at the bottom, we have DTLS, we have STUN, and then we have ⁓ SRTP. And then the other part of it kind of slots into this on top of that. So that's like the three. And DTLS, yeah, this is sort of, it's not exactly where it starts. We could talk through how... how you set up a session or what happens on a protocol level if you want. ⁓ But DTLS sort of comes as a sort of stage two. Once you've punched a hole in the firewall and you know each other's endpoints that you're going to talk to, DTLS is what negotiates the security for the rest of the session. So you use it for both, ⁓ you don't use it for actually transmitting the media data, that's just SRTP, but you do use it to negotiate out the... keys and the ciphers that are going to be used for SRTP. So it's part of that DTLS negotiation. Okay, this very interesting and... like Stun is there because the reality is that you cannot easily reach all residential people. Like when people have a computer on their residential ⁓ router, like in their home, like usually you cannot reach them unless they have like a port open and Stun is there to provide you to make that opening. What I want to clarify is like, let's say you, usually that's with like a server in the middle, I imagine, like, but do you then ever also establish a direct connection? and how does that work? Yeah, so the starting point here is, as you say, it's out of band. ⁓ You need to somehow get this starting point over between the two peers that are going to interact, whether that be a client server or whether it be sort of peer client client, so you effectively have two home users. Somehow you need to exchange some data that is kind of bootstrapping the whole process and that is outside of the protocol that's not defined in WebRTC how you do that. But the most common is obviously that you have a web server where one side can post in their starting point and the other one can pick it up and then provide their starting point back. So you get that's how it usually starts. But that's acting like ⁓ a transport layer proxy, right, forever. I mean, you're not establishing that connection, No, this is only used to bootstrap. this, the way it works there with in the beginning is that you need to sort of know what your public IP is. So you have these processes where you use something called a stun server. Stun is used in two ways here. So we need to keep those things in our head that there are two ways. There's stun servers, which you can use to discover your own public IP. And then there is stun later, which we use to actually try and punch direct holes to the other side. So the stun server initially is just to discover your public IP, you know, okay, this, if I send on this UDP port on the outside of my, my home router, that will be this public IP address. And you want to discover that you want to know what that is because you need to provide that address in the bootstrapping setting up of this RTC peer connection. And that goes in this first kind of offer that you do and you transfer somehow, not defined how, to the other peer. Okay, so discovering your IP address, I mean, that's widely used in general, like you have all kind of services that allow you to discover your IP address even outside of Stun. Is there something specific to that one application of Stun to provide your IP address or is it just the same as any kind of service even over UDP or HTTP or whatever that allows you to discover your public IP address? Well, the point here is that when you talk to a STUN server, you do what's called the binding request and that just a, it's just a ping effectively to the STUN server and you get back what type of IP address you are, but you also get the port. And this is the point when, when you have a home router, which will act as a NAT, a network address translation, you, you bind the port locally on your local computer, which has your internal network's IP. You send this STUN request to the STUN server and that goes via your NAT firewall that then creates a stateful association between a public IP and port and your internal IP and port and then forwards the packet to the STUN server. A STUN server discovers and sends it back. Now this association that you have in your firewall, that must continue to live because this is your hole. That's how you punch the hole in your firewall. So this, this port and IP that you discovered is what you need to provide over to the other side for them to be able to contact back because that, that remains open in your firewall if this works as intended, because obviously there are configurations of firewalls and stuff where this just doesn't work. But the idea is that, this association stays and that someone else can now use that IP and, and port to talk back. all the way into your internal host. Okay, but in the end, I get the fact that your public IP is there, still static, quote unquote, and you have your port, not the public, but the destination IP changes, right? Because instead of talking to the server, you are now talking to another peer. So does it not matter for this port association or socket association? Well, that is the beauty, I guess, of UDP is that it's, it is completely stateless. It's not like TCP where you actually establish a state on both sides that is unique for that TCP socket. UDP sockets are by nature such that you can just send to any other IP import from your UDP socket and there is nothing stopping you. And if a firewall is extremely strict. Maybe it will say, well, actually you were talking to this STUN server and we're not going to allow traffic in from somewhere else on this port at this point. Then maybe you are in a position where this is not going to work out. But typically this actually does work. So the other peer can then talk back to on this same public IP and port and that comes through to you. ⁓ Okay, so that's specific to UDP then, right? Like that's a trick that only... Yeah, yeah. specific to UDP because it's completely stateless. can just take a UDP socket in Rust and you can just say send the packet to this IP with this port and it just does it. does nothing stop you. Okay, very beautiful. I love it already. And so I feel we already sprinkle a bit of knowledge of these different parts of the stack here and there. So I believe now would be a nice time where maybe we could do some kind of a life of a packet or life of an application. So let's say I want to, I don't know. I'm doing an audio call over the internet, let's keep it for now simple. Or if you prefer video instead, also fine for me, but you want to essentially do a peer-to-peer audio or video up to you. For now we have nothing, we just have a webpage. Where would we start? Okay, so we create our RTC peer connection ⁓ object and we configure these kind of stun servers on that RTC because doing this initial kind of communication there, you don't do that yourself. You don't have to discover your own IP address. That's just what's going to happen. But we have the abstraction here. So you just configure it up in there. There's also a fallback. In case this is not going to work, the UDP thing, there's something called turn. which requires you to have a turn server that's going to proxy all your media traffic, but that's like a fallback. And it's also can work over TCP when you're using turn. So these things you can configure on RTC pair connection. You can just say, here is my stun server. Here's my turn server. This is what I need to communicate. And then you will need to get anything going. You need to say that you want some kind of media or you need something to start the negotiation. This could just be the data channel. That's quite a common way to start without requesting cameras and mics straight away. So you could just say, okay, RTC pair connection, stun server, turn server potentially, and then add data channels. you say, okay, I want the data channel in this. That's enough. And then there is a call you do on that, which says create offer. And you get this weird string back, which is called SDP And that offer is what you need to then transport to your friend or to whoever you're going to communicate with somehow, not defined. So you need a web server, you need something, you take this little text file and you transfer it to your server probably. And then your friend's browser picks it up from there or however you decided this is going to work. And then when you get one of these offers, you apply that to your RTC pair connection on the other side. So that one is probably just configured with the stun and turn and data channel, maybe, but you can just receive the offer and that will say, okay, we have a data channel. Okay. So that's what the other side wants to set it start up here. And then you get an answer and that answer needs to go back because STP is a negotiation. you have it, it is sort of both, there's an offer and then it's always an answer that needs to go in both directions. So You need a bi-directional way of communicating with your friend or whoever you're going to communicate with here. Okay, very cool. So there's really a lot to unpack there. Now, of course, we started the connection. Well, we didn't even have a connection yet. We first had to, like you said, you have like a stun server and a turn server. The stun we already discussed because it's about the fact that you need to discover the public IP address and also have an open port that the public can reach or your peer can reach. The turn server you said is used as a fallback, which basically acts like a transport proxy. Is it also just that? Is it just like a transport layer proxy or is more than that? Turn servers are just, it's just a transport proxy. You use, you do what you call an allocation on the turn server and the turn server that, that means that the turn server gives you a public IP and port that you are going to use as to advertise to your, to your friends. So, ⁓ it's, it's just a proxy and it's dynamic proxy. These are typically you have to pay for these because The bandwidth that you're going to use when you're using them is actually going to be something which is not zero. Stunt servers you offer free. Google is providing a stunt server that you can just use to discover your own public port and IP. But turn servers typically you have to pay for to get them. I don't know if there is any free ones. I haven't looked at that. But also I would be a little bit suspicious if someone gives me a free turn server because I'm going to relay all my media through it. So... This is by definition someone who is a man in the middle and why are they giving this to me for free? but you said that we also do add encryption using DTLS and if it's transport proxy then there should be no need for them to decrypt it, right? No, it is true. It is, it is totally end to end encrypted. So in this SDP, this offer and answer, this negotiation that happens. ⁓ one thing that you're sending is these what's called ICE candidates. That's what the technical name for, for these IP addresses that you've discovered about yourself and, and that you want to use for communication. Those are ICE candidates. Another thing that goes is, ⁓ the details about the DTLS session that comes later. So everything here is actually using self-signed certificates. So you create your own certificate on the fly often and then you pick up at the fingerprint with a SHA sum over that certificate and you transfer that as well in these STPs. So that's how the other side later will be able to know when you start talking DTLS that you really are the one that you're supposed to be. So that's how you get an end-to-end encryption between the two sides. that means the turn server can basically send something else to the peer No, because remember the offer, how you get the offer across to your friend there to the other side is not part of WebRTC. So you need to say, okay, but this I'm doing that while I'm my web server or something, turn is not involved. And if you can guarantee that your web server is preserving this offer and answer and the integrity of that communication, then you're safe. Your web server could of course, modify things here and screw things up. But if that's a trusted party, then you'd be okay. Okay, yeah, fair enough, yeah, because like traditionally with HTTPS or TLS, it's because you trust a certificate and maybe you don't trust a certificate, but you trust the root or maybe the root of the root, et cetera. I wonder, well, I guess it was never an issue because usually it is used within applications, but yeah, I would have hoped that there is a way to, I don't know, advertise in a very untrusted manner, maybe like your certificate, like maybe, because you do have things like PTP where people... I don't know, like advertise their public key, et cetera. Yeah. Yeah. I guess, I mean, let's say this was quite, we were very tax heavy people, is there nothing that you could say like, yeah, you, you need to have some kind of domain or social media or whatever, where you advertise your public key and only that one I trust or that's, guess, outside the realm of Vapor Tc. Yeah, I guess that's outside of the RAM of WebRTC. mean, you could make, when you're writing the DTLS layer here, ⁓ how you validate the certificate there is obviously entirely within your control. It's not part of WebRTC. But of course, if you require that certificate to be created by or signed by a specific root certificate or however you do, you could just ignore this fingerprint and say that that's neither here nor there. The only trust I have is you know, this truss chain over here, that's the way we're gonna do it. Okay, fair enough. And then another thing I have a question about in regards to what we just discussed is the fact that, and here you will probably need to correct me because my knowledge is bit off, is that I've often heard people saying that with IPv6 there should be no need anymore for things like a stun or like, I forgot what the word is, ⁓ hole punching, because, yeah, but... I mean I get that for the public IP port because basically every little thing can now have its public IP but I don't see how that solves the port through the firewall. Yeah, I mean me neither. I think that the idea that you could just route any traffic straight into your home private network. I don't know if we're ever going to want that. I think that you kind of want these intermediaries, but I guess I'm not. I am using IPv6 for with this at work, but I am not a very good. I don't know a lot about IPv6. I'm not very good with that. Yes, you say it should be rootable. You shouldn't need to not translate this at all. One place where you do encounter IPv6 when you're working with these kind of media servers is in mobile communication. if you have, if you try to do WebRTC with a browser that is on a mobile phone, it's very likely that you're going to have more success if you also do IPv6 because a lot of mobile networks do that. And obviously always here there there is about getting the lowest possible latency. You don't want latency in your calls. And that's why IPv6 is often could be a better choice in mobile networks because IPv4 might be netted by the mobile operator. Okay, that's fair enough. And then maybe the last question I specifically have around WebRTC because I feel, yeah, it's such a big topic, but like how specifically did you get involved in it? you ⁓ So I've been ⁓ employed now for seven years with a company that uses this. ⁓ And I had a very good sort of childhood friend who's very into C, but he sort of started to be at work. We were basically working with this and I was not deeply in Rust so far that I could do this in Rust. yet, but I was working on the mobile clients. I was working in different places and implementing the other side of this and talking to these servers. I just worked myself into ⁓ understanding. I started writing Ström, which is my WebRTC Rust project. I started writing that ⁓ already, I think, seven years ago. ⁓ I think I've written it like three times before we are at the iteration we are right now. ⁓ Because it's a topic where I sort of gradually discovered, I guess, how this works and what we need to do. ⁓ Writing a rudimentary WebRTC implementation is quite simple. There are a lot of moving parts before you get that magical moment where you see some video actually happening. But there are... deeper levels to it, like say bandwidth estimation and getting that good so that you can handle adverse network conditions. That's when it starts to get like quite deep and you need to like, you know, work, work harder with these things. Okay, very cool. yeah, you said like str0m, you started eight years ago. Is it now like in a, I mean, is it still like what you would label a hobby project or would you say like, yeah, people can also use it for like production use cases. I mean, we are using it for production use cases at work. So I work for a company that records video for a living. It's called Lookback and we do user experience research. we record. It's a bit like a recorded Zoom session, but more tailored to user experience research and that kind of situation. And yeah, we are using it for ourselves in production and it's fine. There are, so it's definitely okay for client server use. Whether you can use it for peer-to-peer, this is like an area which hasn't been explored fully. Probably because the technologies are, you know, but there might still be some rough edges around that. It's being worked upon by, I don't know if I can mention them, but there are some rather large companies that are involved in the development of it that we can talk about. You can find them on our GitHub issues and so on. There is an Australian company which has built a kind of VPN solution called Firezone. They built a VPN solution on top of the ICE agent and the STUN stuff that is in str0m. So... They're actually not using any of the WebRTC and media parts. They're only using the ice agent, which does the hole punching and the setting up of the kind of base layer. So they used it for that, which is basically then to create on the fly kind of VPNs between two endpoints and that kind of thing. So yeah, the code is, I would say it's not battle tested production grade, but it's definitely used in production already. And are there, like I know for example, in things like WebSockets you have like an entire protocol suite called Autobahn. Is there also something similar for WebRTC where you can say like this is an entire test suite of things and if you pass them you probably are fully spec compliant? No. Not to my knowledge. ⁓ I mean, when you start, as I said, when you start looking at these RFCs and the interconnected RFCs, a big problem is to know how much you need to implement all these 90s specs. Because a lot of it you don't need to do WebRTC. And exactly what you need is something you kind of need to just get a working knowledge. There are some RFCs that try to sort of define and these are the parts that you need to look at, but they don't really go into the detail that you need. ⁓ And there's a bunch of stuff in here which are like, you know, RFCs that never really made it past ⁓ a kind of draft stage and they're still like in active use and it's required stuff to do to get it good. it's, it's, yeah, that's. Yeah, I mean that's very typical like there's especially within the browser world there are so many what are like draft RFCs like actively in use and they basically never moved always like being standard but then I'm like yeah I mean what are you waiting for like nobody's gonna ever work on this still and it just doesn't change That's the situation. I mean, Google is very, very driving in this. They have made libwebRTC, which is the standard WebRTC implementation that you find in all browsers. Mozilla did do a little, they sort of done a fork, which they have in Firefox, but this is the big library that is being used. And they're still driving the development of WebRTC and there's very, very clever people that are doing that. ⁓ And they take... in the spec work and the stuff that they do, they think about situations that I never encounter. Say you will find words like middle boxes or they will talk about these kind of legacy telephony systems that they're trying to still be kind of interoperable with, which is not a use case that is very, very relevant to the stuff that I do because I'm not going to try and integrate against those. think, mean, str0m has net is open source, so use it for whatever you want. it's not a problem that I had to face personally in my professional life. So they obviously make these specs and the work that they do given completely different kind of frame of mind and references than I have. And that's probably part of why also the landscape looks the way it does. Okay, fair enough. And then this neatly brings us to our next topic because like str0m is a Sans IO WebRTC implementation. So maybe in your own words, what is Sans IO? Yeah, so I would pronounce it Sans.io because I don't know, I guess you have more of a little French thing going on there. So I'd say Sans.io. I don't know what's correct. Anyway, it's... Yeah, so I guess it means without I-O. Sans.com and Sans is like with and without. So Sans.io is ⁓ a way of trying to build a library without I-O and... Yeah, as long as we understand each other. If we think in Rust terms, then we basically are saying that IO, the thing which is talking, say with a socket or with a file or whatever, is not internal to the library. In strom, when you use strom, you don't, it doesn't open a socket. You don't have a socket deep down. you don't even have, strom is not even generic over something like the read and send trait in Rust. It is none of those abstractions. It's basically all. without IO, IO is not internal, not even abstract. And to just sort of explain how that could look and how that works is that you effectively have just, I guess, two functions, main functions for input and output. You have something where you pull output and you have something where you handle input. So you say, okay, here comes a UDP packet and then... with Rust sometimes and, and the enums in Rust, ⁓ you, you have like a way of pushing that into Strump. So you say, okay, here's my UDP packet. And then Strump does something. It sort of updates a kind of big state machine internally. And then you pull output to say, okay, do you want to respond to this? And then it might be, if this is like DTLS, so I'm getting the DTLS packet in, then maybe Strump needs to respond and provide a DTLS packet out. So then the pull output function will give you output. So you get this kind of, you handle input, you get some input in and then you pull output and one input might, one input thing might result in multiple outputs. So you get this kind of loop going. So you handle input and then you pull output, pull output, pull output. And that could be like multiple things to send or maybe it's like events, like maybe it's media data that came in. Maybe the packet that came in was an RTP packet. So out, you get media data ⁓ in the output. So this is the way that you could then build a library that completely does not have the IO internal. It's just these kind of two, essentially two functions that are central to how a DSLStorm is structured. And this is a pattern that I picked up from other places. If you look at QUIC, which is, no, QUIN. So it's the QUIC protocol. One big implementation, which is production ready and used in Rust is called QUIN. which I think you had Osman on this show a couple of weeks ago, right? So he wrote that. And if you look at, there's a crate called Quinn Proto. And that one has exactly this pattern of Sans IO for the underlying protocol implementation. that's, what does that give us? Okay, let's talk about like, why would you want to do this? It sounds complicated. ⁓ beauty here is like if we think about async and sync problem in rather problem the situation where if you want to do IO you have all the kind of built-in IO and then you need to make a decision. Am I going to use blocking IO or am I going to use the async IO with Tokio and the rest? If you go for sense IO implementation you can sort of sidestep that question and just not deal with that because Whether or not you use strom with an async framework like toki or you use it blocking That's that's not something that we need to worry about because the IO is not part of strom It's not in there So the blocking only arises when we need to wait on a socket or wait for a file or something like that And if those calls are never part of the library, you kind of side-stepping that entire problem So you have, you know, there's like efforts right now going on in Rust where they're talking about being generic over keywords. Should it be possible to be generic over sync async? So you could write something that can function as both. ⁓ And that problem is kind of sidestepped with Sansa. You don't need to think about that. That's, it's just sync. We just do things. ⁓ And I think for me personally, in terms of the async thing, I mean, The async story in Rust is amazing. think that, you know, the work that, I don't know, without Boats and like he did that pin struct and all of that kind of stuff that sort of made it possible to compile out this, the state machine that is the async stuff from, from Rust. It's totally mind blowing and it's great. And obviously there are cases where you absolutely have to use async because you want to scale on IO. Like back in the day when I was doing Java, you know, you would start a web server with like hundred threads or something because you might get a lot of incoming connections you need to handle and then Node.js came along and we just do it with one single process and it's fine because it's async. So there's obviously you need to handle async and there are cases where you want async but for me personally I think sync rust is like the most beautiful rust. ⁓ If you look at the the borrow checker and everything that comes from that, then for me, the ampersand mut self, when you have like the mutable reference self, that is like, for me, it's like, Ooh, it's so good because it effectively means I can do things, I can do fearless concurrency without needing to worry about that. That's all handled by the compiler. And you probably, if you've written some async code, you know that if you do mut self, you you will have pains because it basically locks up entire kind of structs for you as you are waiting these I-O calls. And that's, I love that part. it's str0m for instance, hasn't got a single mutex or shared or arc or anything inside it. the, going with a kind of purists ⁓ mindset here with Sans I-O, I can actually use rust in the most beautiful and way that I think is possible and I just love to engross. That's what I think. Yeah, I mean, in a way I agree and actually I think it's less complicated. Like I find like a pattern that in general holds up true. seemed like, mean, so something most people will, because not everybody's implementing protocols. do make, it makes a lot of sense to protocols, but you can even like, kind of like bend the concept a bit and think about things like a typical web server. So let's say someone was making a web service, like I don't know, some kind of e-commerce business thing, whatever. What most companies will test is actually using some kind of HTTP client and actually talk to the server and do the entire, I don't know... Protocol dance and what they really just want to test is test their entire business tech Which means once you already decoded the Ion requests like what you want to do with that request so then you go through entire middleware and like do something and server response which was back to your middleware and do that and What I find mind-boggling is how most companies actually test on top of that also the entire transport layer and encoding and decoding of requests even though they are probably using something so widely used that I mean, there is certainly a use case for it because sometimes you might be doing something so specific that you might trigger a bug because of something in the IO layer. So you might want some of those tests, but I would think pretty much all your business tests you don't need that for. And so it's not really what sounds IO, but it's still what you do see in some Rust frameworks that are based around Tower or something where they are able to just, is a request, I expect this response. ⁓ beautiful as well because you can you don't have to worry about an entire binding to a socket or streaming or this or that and And so when you were talking about applying Sounds.io in a protocol setting, to me it also makes sense because you really just want to worry. I send these bytes to it. I give these, or maybe I'm doing a read, I'm doing a write, et cetera. After this pattern, I expect also these things. And they're beautiful like libraries that allow you to just say like, I do a read of this, I expect a write of this, a read of this. And it makes testing so easy. ⁓ Mm-hmm. Yeah, I I definitely think that SansIO is something you can use. You can use in other situations as well. You don't need to say that this is just for protocols. I think a server could, you could structure your business logic in a SansIO way as well, which means you have a sync crust and then you would have an async part that calls into this sync crust. There are some things that happen in SyncStrom, which means that it might not be, whether or not it's... It's great to put it on an async thread is unclear because there is some encryption in there. So encryption is typically like CPU heavy work. So it's the kind of stuff that should I actually be using like a block in Tokio terms, should I use a blocking kind of thread for this instead of just spawning it on my regular scheduler. There are some concerns like that because obviously it's, it is doing something. The encryption is, is encryption. It's just, it's what it is. Whether or not that's suitable for Tokio, like just straight up in Async, up to the situation, it's hard to give recommendation. I think that, yeah, I think that right now the whole Rust ecosystem around Async, was just gonna say that Async is like, because we are so focused on Tokio and Tokio is amazing, of course, it's a great work stealing Async runtime, but it forces this kind of sense. sync thing because it needs to be able to transfer the tasks between for the work stealing. That's sort of the point here. But that's become like the way that we do it. And that sort of then shapes all the code in its way. So you kind of end up with these MPSC channels with senders and receivers, or you have an arc mutex something something state that you kind of need to share between everything because that's how you then going to and... I just think that those patterns kind of lead you to software architecture that doesn't feel great for me. I don't want that in my code if I can avoid it. And I've written servers like that, of course. It's impossible to avoid sometimes. And if you look at frameworks, if you'd like take, we work a lot with AWS and their entire kind of catalog of official libraries are async. So you kind of end up there if you're not going to write everything yourself. It can be hard to visualize, to get this sense I.O. ⁓ ideal that I'm aiming for. But yeah, that's where we are. Yeah, well, so two things about that. Like, first of all, I agree with you because in a sense, like, that's how most people perceive Tokio and also for some use cases is anyway the most optimal where like people use indeed like this kind of work stealing mode. But then we talked in episode 15 with the Glott flair folks. who work on things like Pingora and Oxy. And they actually tried for their specific use case, so that's like high traffic, kind of like ⁓ proxies or like tunnel kind of applications. And they tried work stealing and non-work stealing. Non-work stealing meaning they spawn threats and then actually have like a Tokio runtime patch threat where you no longer need the sync bound, which is the most tricky one. And then, yeah, they did see that for that work load. Like the work stealing was the most efficient and at some point they want to make a blog about it But they find it tricky, but at the same time I agree with you there you it's it's a bit of a shame that first of all it doesn't apply to all applications there is more than proxies and secondly, you don't want that to kind of like pollute everything and then yeah, that that's one thing and then next to that is so you were mentioning about encryption and the fact that, okay, so I have two, one thing that I want to say, one question is, so we have something similar in Rama where we have like, example, Rama WS like WebSocket. And then next to it, we have some sub crates and one of them is Rama WS. And that one is also implemented ⁓ in a Sans IO way. And then where we do want to like bind it to something asynchronous, we kind of just wrap it. And so that allows you to still pull on it, which would be same for your case, like maybe this encryption part is a bit like heavy, but you kind of like can poll on it. so then you can still, I don't know, you can wrap it that it becomes non-blocking anyway, because maybe it's not ready yet and then it kind of works. But you would kind of need to weigh how, know how to course split up the work. But what I do wonder about, if you anyway go for a sounds I.O. approach, why does the WebRTC layer need to know about the fact that it's going over DTLS? Shouldn't that be like a detail that doesn't matter? It matters a lot in the sense that the keys that you need for SRTP, the secure RTP, they come out as a byproduct of the TLS negotiation. So there are these extensions that you can have in TLS where you say, oh, at the same time as you are negotiating the kind of the keys for, you know, this like Diffie-Hellman and this kind of protocols to, to, to negotiate out some shared, shared secrets. You can have these extensions that also gives you like keying material for the users. And that's what's happening here is that out as a by-product of the TLS negotiation, you get the keying material, which is then shared on both sides. So they have the same kind of secret keying material that is then used to derive out. the encryption and decryption keys that you need to talk SRTP. So. I, okay, but wouldn't you normally like abstracted away maybe where you would say like, I have this abstract concept of like, I have this key material. And of course in production, that would mean it comes via some kind of, ⁓ like crypto library, but for your like testing and all this stuff and actual protocol things, wouldn't really care where it comes from, right? Yeah, I guess. mean, you could potentially sort of pick apart something like str0m into smaller bits. It sort of still becomes, I don't know, at some point you need you need to decide what level abstraction you are, I guess. And if we say that one abstraction that we have in the browser is the RTC peer connection, which definitely has all of this stuff. underneath it. The question is, if I provide strom, like how much of a kind of building Lego blocks do I want to give the users of strom? I, this is a philosophy I have both for UREC and strom is that I, I want things to be as user friendly as possible. I'm a big proponent of using say built in Rust types. Don't go over crazy with like weird trait signatures because you want super flexible functions and whatever. I want as far as possible to think about it. A beginner to Rust should be able to read this and understand what's going on. And here for WebRTC, which is already like a complicated topic, mostly people will come from the browser. They will come from RTC peer connection API that they've encountered in the browser. And to provide something which feel, it's still different because there was some big limitations that means I can't implement it exactly like that. But it needs to be familiar. It needs to be some kind of level of abstraction that is similar. you know, people are talking about batteries included. What does that mean? It's like, what are the batteries? Should it do this or shouldn't it do this? Should it be a separate part? And here there is like a part which is actually being discussed right now in our GitHub issues, which is whether we should provide the turn server ⁓ usage, whether that should be part of str0m itself. And here is the distinction I've been making so far is that I turn, when you kind of relay your data via a third party proxy, that's IO to me. That's, it's not something that str0m needs to handle itself. It could do, but it doesn't currently. So right now that's sort of something which it doesn't, isn't built in. And if you want turn, you would need to use another library. talk with the turn server. So somewhere you need to draw this line. And I think DTLS for me at least is like, is very involved in this because then you have the data channels, which is that part where you, which is the alternative to web sockets. On top of DTLS you have something called SCTP, which is another protocol for, which is for sending data. And it can be done reliable or unreliable. And SCTP then directly uses the DTLS layer. to send individual packets. So for me, breaking those things apart, possible, but it would be quite complicated to get an API surface for that and kind of have that outside. Yeah, I understand. So I will tell you a bit where I come from. It's because like when you mentioned things like, ⁓ okay, I have the AWS API and, they come already with async. And it's also usually because they already come with like a build an HTPS client and all this. And so it basically means that, so where this becomes an issue is not for beginners. And so I would always say, if you make something like str0m, it totally makes sense that you come with batteries included and you can just kind of get started with a simple example. that is the happy use case or the beginner use case. But then the problem comes for me when let's say I'm working for a company and I'm building my application, whatever it is. And as you grow in terms of requirements and needs, you like bring in all these dependencies, which is kind of like unavoidable unless you want to like write everything yourself, which is something we used to do when I was working in C++. We kind of like wrote everything ourselves, but... Nowadays it's not so common anymore. We can talk about that, but not today. And like then you get into this, I don't know, in the best case scenario, it just works and everything kind of like, I don't know, you have maybe like five different HTTPS clients or five different HTTP clients. But then the problem is often like something with cryptography is that maybe not compatible because you're only allowed one cryptographic provider. But at the same time for me, at least when I develop applications, like as little. (amount of) dependencies as possible. And so for me, it would be a bit silly. Let's say I already have something that does everything on the network layer to then also bring in three different HTTP clients. And so I get that you want to avoid that for the beginner. I totally, I would say that's the right choice. But you would also ideally like to prefer the ability to opt out of that at least. Like where you can maybe say there is a way to at least bring in your own client. so for example, if you look at something like, I'm not sure if you're familiar with it, but like things like tracing in Tokio OpenTelemetry. Like in OpenTelemetry, they come in with these built-in like gRPC providers, HTTP providers, but you're also allowed to just use your own. And that makes totally sense then because now I avoid Mm-hmm. Mm-hmm. Yep. Hmm. having to bring in a second network stack because I'm already a network stack myself so it's a bit silly to then need like a second one and so yeah that would be my issue a bit with like something like str0m and it's not like criticism it is more like maybe that would prevent me from using it because I already have plenty of cryptographic like support maybe I would like to just use that Yeah, mean, DTLS specifically, I don't know if we have time to talk about it, this is a, with WebRTC and talking to browsers and getting that interaction to work, you don't have many choices in Rust to do DTLS. You have TLS library, have Russell's, which is great. you spoke to people from there, the Russell's is amazing, but it doesn't do DTLS. And DTLS is not miles apart from TLS, but it's just one of those. It's it's apart enough that it's not like it's easily under the same umbrella. It would need some work. And therefore, and then it's also like, you need to have DTLS 1.2. And right now, TLS 1.3 is like the big spec that everyone uses. And there is DTLS 1.3, but we haven't really moved into that in WebRTC. We're still using 1.2. And this... makes it possible, you know, you could have this possible to switch out, but ⁓ the choices you have are not that many. And ⁓ there certainly isn't like a common API around that. So we would need to then also come up with, I guess, a str0m specific API on how you plug in these cryptos and have adapters for various crypto providers, etc, etc. So it kind of leads to more More complication to make that possible. ⁓ So far, Strum has been using OpenSSL ⁓ and we're trying to migrate off that because ideally we want the kind of pure Rust solution. ⁓ But this has been pretty much only because DTLS has held us back and OpenSSL is one implementation of DTLS. ⁓ But yeah, we currently just have re-implemented this in our own project called the dimple, which is like a DTLS implementation that is then going to be used in Rust to try and get rid of the open SSL dependency. Very cool. Yeah, I do have a feeling we kind of have to start round off like even though I could talk to you forever and and I and if you want me I will definitely invite you again in the future where we talk about some of these topics or related topics because it's a very pleasant conversation but now before we round up I do want to give you the opportunity like maybe there is something that you do want to make sure we discuss or make sure you want to mention and then next to that you are free to plug in whatever you want and then I do want to give you the opportunity at least. Well, I mean nothing specific. I love to engage with people on this. Maybe I said something today which is completely wrong. I could have got something WebRTC wrong, point it out to me. We are available on GitHub and I'm sure you can provide the link in the show notes. And we're also on Discord if you want to chat with us. And yeah, I love to talk about that. I love to talk about Dimple, the DTLS implementation. I am not a crypto person and this is the first time I've written something like that and it's... very scary because I don't know what I've done wrong and what that would lead to. So yeah, all of those things are like, there are many people out there that are much better than me on those things and I would love to get feedback or to discuss or, you know, take these things in different directions. Like the ICE agent, for instance, there is talk about, you know, what should be spin out on Crate because more people might want to use that, et cetera, et All of these like possibilities and yeah, I'm open to talking about all of it. Yeah, very cool. I will also link to it. So do provide me with the links of those projects, especially the ones you want feedback on. I will include them. And yeah, I have a feeling I'm going to invite you again, probably specifically around DTLS or some topics like that. But in general, I am very grateful that you had some time for us today. We learned a lot. think a lot of us or listeners are probably not aware yet of WebRTC. And I feel that you did a very good job at explaining that. I also feel that the world can use lot more Sounds.io because it's pretty great and I'm very happy that there are folks like you that are pushing the boundaries of it, so thank you very much for that. Yeah, thank you for having me. It was great to talk about these things that I do every day, but I love it. Very cool. Have a nice time the rest of the week. Elizabeth (Plabayo)
1:18:38 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake.