 I have been dabbling a little bit with WebRTC. Oh. Exactly. I mean, we can stop the topic right there. We pretty much already spoiled the conclusion. Not even that. That's all I know about WebRTC. That is the first thing that already annoys me. So WebRTC has been around for a good amount of time. I want to say at least four years because I know that Sam Dutton's article on HTML5 rocks is from 2013. Yes. So it's been around for a while. Yes. It allows you to basically create a connection to another browser that can be even on a different machine, even on a different network, theoretically. Video calling. No. Exactly. No. Yes, but no. No. No. So, I'm going to expand first and then give you the mnemonic. Okay, okay. By default, WebRTC connections are established by you figuring out your own IP addresses. So you figure, I am available over localhost, then you get your local IP network IPs. And that's pretty much it. That's what you send over to the other client and they try to connect. What you send to the other client, I'm available on localhost. Yeah, if you're on the same machine, that works. Okay, I see. Right? All the possible addresses that you know you could be available under. You somehow pass to the other client and then they try to connect. Oh, so you find them all and it just tries them? You can. Yeah, you get in a series of events for ICE candidates and ICE is the protocol on how to establish your name. Oh my God, this is full of an ICE candidate. But that only works if these peers are on the same machine, so localhost works, or on the same network without client separation, which most public hotspots have. Right. So if you're at home and you have your phone and your laptop, this will most likely already work without a stun or a turn server. Okay, because they both know their IP address on the same network, they can talk to each other. And then you establish a connection with all... Nothing leaves the house. Yeah, with a web artist's shenanigans, which is another completely different and super awful topic. But if you're not on the same network... Right. For example, you're roaming, if you're roaming, you're out with your phone, which has a proper public IP. Yes. So no firewalling, but just a public IP. The phone doesn't know its public IP necessarily. So that's when a stun server comes into play. The sole purpose of a stun server is to receive a request, figure out which IP this request came from, and give back a signal in a web artistly compatible way that says this is your public IP. So you can add that to your ICE candidates because that's another IP that you're potentially reachable under. If, however, you're behind your router at home or you have a firewall where incoming connections are blocked or you actually have to do some netting to get back to your actual connection. Some netting, we'll go over that. That is where the turn server comes into play, which is a server in the interwebs that both sides connect to and tunnel that traffic through it. And the way to remember, to me it's like, turn has the R, which stands for relay. That's a difficult second album, mate. It's how I remember it, honestly. No, your... Yeah, your Flexbox ones were a bit better. It was better, but that's the morning I have. That is the relay server that relays your traffic instead of you to the public interwebs so both can connect, even if both ends are behind different firewalls in different networks. In my experiments, I haven't even bothered with setting up stun or turn because I was like, I'm just gonna... Because what I was doing, I was once again playing around with comlink and I wanted to expose the entirety of one browser to another browser. So basically, I've exposed the entire window object of Safari to Chrome and I can change the title of the Safari window from Chrome by calling document.title equals blah, blah, blah. But it is actually a remote object from the other browser with a WebRTC tunnel in between, which is super cool. But getting there was a super painful experience because you can totally tell that WebRTC was written by people who are in telecommunications and other web development. I do find that the web standards, even the standards text and the APIs, it does look like it was imported from another planet. That's a completely different way of thinking. It starts out with B that it's already completely asymmetric to start with. So you start with creating an offer that contains what you are and once you say this RDC connection, the local end, should fit this offer, whatever that means, you get ice candids, which describe yourself. Sure. Help. It's super confusing. So you create an RTC peer connection, even though you don't have a connection yet. That's the first thing you do. You create a connection you don't have. Then you create the data channels you want to create because you need to know what kind of connection you want to have in the end. So even though the connection hasn't been established, you're already thinking about channels and creating the objects. Then you create this offer which describes, I guess, what your capabilities are. You can do these codecs. I can accept data channels. I am the passive listener waiting for connections. These kind of things are in there. Something that can be a lowest common denominator. I guess. And then you say to the connection, set local description where you say, I am on the local end and we're going to do the other bit. So you set your local connection and you get a list of your candidates. So now you have the offer and your candidates and now it is your responsibility as a developer to get these two things, the list of candidates that you offer to the other side or to the other peer that wants to connect to you. So peer discovery is not even covered by WebRTC. You already need to know and have a way to communicate with the other end to set up a WebRTC connection. Oh, so that's separate from a standard return server, that part that can actually sort of broker the deal between two. You already need to know where to talk to to set up the connection. So that's why always you have a signaling back end where you basically say, here's my offer. Here's my eyes candidates. And then the other end, the other computer basically gets those and sets what the offer as its remote description because from their perspective, that is the other end of the connection. Right. Oh, so you're talking to the... The second computer wants to... So you have one computer and the second computer, they want to have a WebRTC connection. Yes. Then somehow out of band you transfer the offer and the eyes candidates to the other computer and that one uses as its remote description because that is describing the other end of the connection. But then this side has to also generate an answer and another list of peer candidates and it has to go back out of band. Then this side says the other, the original side says, this is my remote connection and then you can communicate. And it is, it sounds confusing because it is confusing. Do you know what index TV sounds great now? I know, right? It's fine. It is... Perfect. It is mind-blowing and that is expense me. Anyway, nobody is really using it because it is really difficult and B, the first thing people did is write abstraction libraries on top of it. But being able to, like the end result that you got to with the data channel of being able to sort of have like one browser talking to another as if it is just in a worker, that's pretty incredible. I see potential in combining WebRTC and Comlink, but there's work to be done. They also played Sailor V by Bewitched and just asked for one extra bonus point who knows what this song is. I know what that song is. So do you know what that song is? Homework View is the best song ever. It's an Irish girl band. It's amazing.