Hi, my name is Sean. The project I work on is called Pion. Pion is a open source collective for building real time communication software in Go. It's completely driven by individuals. If you're ever interested in getting involved in open source, we'd love to have you work on the project. We have multiple different companies. We have students that want to learn Go tour real time communication more, and we have all these different types of communities as well. We have people that are working on security that are interested in dTls. We have people that are just interested in building conferencing software, and we have robotics, just to name a few. So we'd love to have you involved, and we'll talk about later where you can find us. So if you're not familiar with real time communication, go is making a big splash in this space. And here are some of the companies and the projects that they're building. Format is making it so you can remotely control robots over the Internet. So here's one of the Boston dynamics spot, and it has the format agent on it. And with that, I can now control it over the Internet. So in the bottom right corner, you can see that I'm using my mouse and keyboard to move things around. And with that over the Internet, I'm able to move the robot up and down, and I'm able to transmit the audio and video directly into my browser. Headroom is making it taking conferencing to the next level so you can analyze. When you hold up your hand, it'll automatically say that you're raised. It'll do speech to text, and it can measure how much eye contact has been made and other things. It's what can we do with all of these great libraries in Go and audio and video processing? Piepackr allows you to play games with other people directly in the browser. So on a remote host we have this NES emulator at Super Nintendo Game Boy, and it brings all these classic retro games together and makes them able to play. They're using Pyon to run on these remote those, and then you're able to connect directly. It kind of recreates that sitting on the couch next to a friend experience. Here's another is strive has a peer to peer CDN using real time communication. Peer to peer, they connect people together that are in the same network. So you only have to download a video file remotely once. So you have the CDN Edge server. I download my video file once and then I share it among my users. So you don't have to use an Internet connection to download the same file ten times for these people that are in the same network. So what is WebRTC? We talk about all these really cool big things you can build, but what exactly does it get you? WebRTC is originally envisioned as a protocol for browsers, so it gives you end to end secure connection between peers. So two browsers, they're able to establish a connection directly. You don't even have to go through a server and it's completely secure. So there's no optional, it's not like HTTP, HTTPs, if you're using WebrCC, it's a secure connection. And then you have two things that you can exchange. You can either exchange multimedia, so I can do two audio, three video tracks, there's no limit at all. And binary data. And binary data with WebRTC is very interesting because it can be lossy and unordered. So if you think if you're building a real time system like a video game, you don't care these, the player was 2 seconds ago. You just want to hear what's happening right now. So it allows you to build really interesting systems with that. The other really exciting thing about WebRTC is how widely available it is. So if I have two WebrTC agents and they're exchanging binaries data, I could have one in Python, I could have one in typescript, I could have one in Java and one in go. I think WebRTC is a great chance to have things cross language communication without having some kind of central server. So a lot of issues today is if you want to have two languages communicate, you have to run some kind of pub sub server, or you exchange things via HTTP with WebRTC, I can connect these two processes together directly and start exchanging binary data and maybe send JSOn over or whatever I want. And if you're curious about WebrTC really works, the pion community is working on a book called WebRTC for the Curious, and we talk not just about the public APIs, but a deep dive on the protocols and how things actually work. We also have some interviews with the RFC authors and the people that actually made WebRTC, so you can understand the intention of it and what the purpose and the design of things. And also like a WebRTC in practice, if you need help debugging or teach you the sharp edges, I think a lot of those things come in handy if you don't want to have to learn those things in production. So we provide this resource for you. So what does WebRTC solve? I promise all these really interesting things, but until you hit these problems, you probably don't appreciate how great WebRTC is. And another thing is you don't even realize some of these problems are solvable. So a lot of times users think, oh, I want to exchange this file with another person, but we're in two separate networks, so I have to upload it so we can both exchange it. But that's actually not true. I can connect two users with no public IP who are on completely different networks. And it uses this technique called Nat traversal. So every time that you send a packet out to a public server, your nat will establish a temporary hole. And that temporary hole allows these server to send messages back to you. But you could also share that temporary hole with other users and they can send messages back to you. So let's say you say, send a packet to google.com, your nat opens up a temporary hole so Google can respond to you. But that temporary hole can also be change and told to other users. And these can send messages into you. And what WebRTC uses is something called a stun server. And so the stun server, you send a packet out to and you say, hi, please send some data back to me and also tell me what is my public IP and what is this temporary hold that's established? If you've ever done port forwarding, maybe to play a video game before, it's essentially like an automatic port forward. WebRTC also solves the problem of staying connected on these move. So let's say you originally take a call when you're on Wi Fi, but you decide to walk outside. WebRTC provides this thing called ice restart, so it can actually measure the connectivity, the quality of the connection. It can switch connections on the fly and always pick the best route. If you're using TCP, there is multiplayer tcp, but the nice thing is with ice restart is it switches and the user land is aware of what's happening. So I can switch, let's say, if I switch from Wi Fi to cellular, I can say, okay, like I need to send lower quality video because I'm on a metered connection and stuff like that. There's a lot of powerful things you can do if you're aware that you're switching networks and you're aware of the quality of that network. Another really common problem is that users will sit down and they'll want to measure, they'll want to say, how much bandwidth do I have available? Because that's the quality of video I want to upload. But that's not how the real world works. When you measure, you could be measuring when the network is really overloaded, and it could say you have less available, or you could measure when the network is really underutilized. And as more people come on the network, you have less bandwidth available. So here's an example where I originally measured and I thought I had 50 megabits a second. But as more users come on at different hops, all of a sudden that reduces the actual bandwidth available between me. WebRTC has receiver feedback, and what that allows you to do is implement congestion control. So when I receive media from a sender, I send responses like, I got these many packets, I lost these many packets, and I have this much delay. With all this information, I can actually adjust the bitrate and make sure that I get the best experience possible. So if you've ever done a call over WebRTC, you'll watch. The quality will fluctuate as the congestion of the network change. Another popular thing that people use WebRTC to solve is the head of line blocking. So with TCP, the first message that you send has to be delivered before message plus one. The nice thing about WebRTC is that you choose what is retransmitted. So let's say that you can send a message like telemetry, metadata, something that isn't important. If it doesn't get delivered, you don't have to try to send it again. You can mark that message with a max. Retransmits of zero and new data now flows unblocked and delivery. But let's say that you do care about something. You can guarantee that it's been delivered by resending and send, a receiver will say, okay, I've got message with this transmission number. Another really popular thing about web receive is actually a bundle of existing protocols. So if you've ever worked in VoIP, you've probably heard of RTP and RTCP and SRTP. It's really easy to bundle all these existing things and you can hook WebRTC up to an existing VoIP system, or you can easily bring in a call from a plain old telephone system right into your WebRTC call. Being able to bring all these things is super powerful. So now that you're convinced that WebRTC is super exciting, you're going to build something. You go and check, but Pyon and this is how easy it is to build something. So with WebRTC, since it's peer to peer, we have to exchange some kind of metadata to say, okay, this is where I'm located. These are the codecs I support. And this is what I want to talk about. And this is known as signaling. So what you do is the person that wants to start the call creates can offer, and the person that wants to connect to the call creates can answer. WebRtC is always a one to one connection. So here we are on the offering side. I create a peer connection, I create an offer, and I send off my offer. At the end of this file, you see, we get the remote session, the remote description, and we call set remote description. So now we have just with things six lines of code, and you'd have the equivalent. On the other side, you've established a peer to peer connection. You can now once you're established, create a data channel. You can create as many data channels as you want. I think there's actually a limit of 65,000. And each of those data channel can have settings that control the lifetime, the priority of it, and other things so that you can tailor them to what their purpose is. So on the first line, I create the data channel, and then when the data channel is open, I send the message hello world. On the other side, I have an on data channel handler, and when a new data channel opens, I print the name of the data channel and I print the messages has they come across? Really exciting thing about WebRTC is since it's available everywhere, you can actually write your WebRTC code in go and then deploy it to webassembly. So that's what I've dont here is I've taken my existing example and I've built it for Webassembly and now I use it right in the browser. Sending video is easy as well. You create a track and then you start writing some media to that track. Here we are. IVF is a file format that just contains raw media data. So we're just reading frame by frame and then writing it to our WebRTC connection. And then on the other side we're receiving frame by frame. And WebRTC has all this goodness built in where it will measure the amount of bandwidth available and tell you like, this is what you should do and it will handle loss and other things like that. So here's some of the really exciting things that are being built with Pion and open source. NS remote allows you to send the video data right from a Nintendo switch into a virtual reality headset. So a user has put pion on a device that captures the frames from the Nintendo switch and then sends it over the network. So they can sit with a Nintendo switch in their hand, but they get a full immersive experience with the headset. It does these cool things like, because you're on the same network, you're not paying for the bandwidth to have to send this over the Internet. And this could also go to other devices. Because WebRTC is an open protocol. You could send a Nintendo switch into your browser, you could send it to your tv if it has a WebRTC agent. It's kind of a ubiquitous protocol at this point. WebRTC is also great for security cameras. So there's some existing protocols for security cameras. You have RTSP, or maybe just plain RTP. But one of the issues is that that doesn't handle Nat traversal and there's not a required security for that. So RTSp, you could opt in to have encryption, but with WebRTC, since encryption is mandatory, I think that it's bringing a lot of great security to the space. Neko allows you to run a browser on a remote host and then have multiple people connect to it. So you could watch a movie with a friend, you could browser a website with another person, or you could use this to run a heavy web process on a remote host. You could run Slack and watch YouTube videos and stuff like that, things that you don't want to do locally if you don't have the processing, you know, again, just like the early example earlier with format, here's an open source implementation of that where they put a py on directly on the drone, and now you're able to control it by dragging things in a web UI and then they're sending the video frames right over the Internet. WebRTC conferencing doesn't just have to be in the browser here you're running a go agent directly in your terminal and it's doing a encoding and decoding. And so now I'm seeing another user's video frames just in ASCII. And if you're familiar with a lot of the cloud gaming projects, we now have that with an open source version, cloud morph, you can get that right off GitHub, and you can play Diablo two, you can play StarCraft. And it's also great for running like heavy applications that are difficult to set up. You can spin up a remote host and run something, unwind that's really difficult to run and set up, and then tear that host down so you can play across different devices, you can play it on devices that don't have enough gpu and things like that. And I see a lot of promise with WebRTC and exchanging like terminals. So here we have WebRTC which allows me to connect my terminal to a browser and I don't need to run it through a central those and I actually dont even need to be on the Internet since it's peer to peer. I think there's a lot of promise here. If someone was to come up with a project that could allow you to connect two hosts or maybe two containers without having to worry about central processing, and you could have it be multi cloud. And there's a lot of interesting things here that I don't think has been fully explored yet. Snowflake is an open source project by Tor that uses WebrTC for censorship circumvention. So instead of having to download the full Tor browser, you can just access a website via WebRTC and the data channel. And this is great because if your ISP or your network provider or maybe a government wants to block web tour, it's a lot harder now with WebRTC because you have all of this conferencing traffic and other important things that go via this protocol, so it's much harder to filter and identify. Webwormhole allows you to change files via WebRTC and now you've seen a lot of examples like this just in the browser. But now that we have a go agent, it brings up a lot of interesting possibilities. I can send a file directly from my server to my desktop, I can change things via my phone, go bring it to a lot of new platforms where having a full browser wasn't possible. And Pine is being used for a lot of interesting conferencing things as well. So here is a virtual reality space where people's heads are imposed upon their avatars, and they did some really cool things where they actually had Shakespeare that was performed in this, and that's great for things that you couldn't do in the physical world, like quick costume changes or changing the stage you can quickly do in VR. So I think it opens up a lot of interesting possibilities. So if you go and build something with Pion, I'd love to hear about it. We have GitHub.com slash Pion awesomepion with a list of all of these things that I think are really promising and exciting, and we'd love to have yours as well. And Pion needs you. So if you're interested in getting involved, we'd love to have you on the next slide. We have the slack and email, but these are kind of the reasons that I love working in open source is you get to empower those that are helping the Internet. So Tor ipfs and there's a lot of great projects out there, and you gain deep WebRTC knowledge. It's really great to work on Pyon and learn this stuff and then not have to learn it when you're solving a production issue. And in that same vein, it's a fun challenge where you pick the goals. If you find a particular part of WebRTC interesting, here's your chance to deep dive on that in just just enjoy that. So that's where you can find the Pion project on GitHub and these we have a slack on the gopher slack and then a Twitter where I share interesting project updates. So I hope you found that interesting and please reach out anytime and I hope to hear from you. Thank you.