Hello, everyone. This talk is very related to the previous one, actually. It's a WebArtistic project I've been working on lately, but it's on a much smaller scale. It's just me working on this. As he said, my name is Mauro. You can find me on Twitter there.

And Vemux is a project I started like a few months ago to basically reproduce the functionality you have now in Skype, but using WebArtistic technology. So you can have, like, chat and video call in the browser, but without using any plugins or Flash or the need to

install anything else. And it's also being built on top of WebArtistic. It's peer-to-peer and it's encrypted and secure. So I'm going to go about WebArtistic and explain how it works. I've seen that there's a lot of people that are aware of WebArtistic, right? Can you raise your

hands? I'm going to give a brief introduction about how it works and then explain a bit how Vemux handles all the WebArtistic stuff. WebArtistic is a really, really exciting project that's been going on for a year, maybe even more than a year. And it's basically a set of JavaScript APIs.

I'm going to go back. It's a set of JavaScript APIs that enable you to access input output on your laptop or in your system without doing just anything else.

If you think about other products that already exist, like Skype or Google Hangouts or like any other proprietary system, usually it's really hard to integrate with other stuff. Sometimes in the case of Skype you have to install applications, you need plugins for Google Hangouts, etc.

And the advantage of deploying something that runs on WebArtistic is that it's almost everywhere. You don't need to be aware of building your application for multiple systems because it basically runs on the browser and the browser takes care of it. Basically it's a very big abstraction layer on top of that.

And it's been advancing really fast in the last few months, so now you have WebArtistic that ships on Chrome, on Firefox, on Chrome for Android, on Firefox for Android, Opera, and then you have also bindings, native bindings if you want to do something

like this WebArtistic client that runs on your Android app. It's almost everywhere, it's quite ubiquitous. And then this is what it does basically, it's a set of JavaScript APIs that give you access to input devices in your system, so let's say the laptop, the camera,

and the microphone. Then there's another set of APIs that allow you to communicate with a remote peer directly from your browser, and you can send arbitrary data using a different one. These are abstracted in these three APIs basically.

The media stream, which is for audio and media, there is a connection and the data channel. The media stream is just called, you see here, it's called actually getUserMedia. And what it gives you is a synchronized audio and media output, and when you instantiate this, when you call navigate to getUserMedia, what you get back is a media stream of your camera

and your microphone synchronized. You can also pass constraints, like you can pass the resolution you want if you want multiple resolutions, if you want, if you are like, what is abstract actually, if you are on a mobile phone, you can choose what camera you want to use, etc.

The RTC peer connection is kind of like the main component on WebRTC, and it abstracts you from a lot of other stuff. It does all the signal processing for you, does all the encoding for video and audio.

The codecs that it uses are royalty free and open source, like Google bought the company that used to do VPA and then they released it openly. And have the security, so each, with the communication between each peer is encrypted.

They exchange fingerprints when using the signaling, and I'm going to talk about that in a minute, and bandwidth management. This is basically how it looks like, it's like very, very simple. When you have basically callbacks where you can say, when you get a remote stream that is a video or audio, and then you can do something with it, like attach it to a video element on your page,

or the same thing with your local stream, and then you can create offers to offer the local descriptions you have to someone else. And then you have RTC data channel that once you have established this connection between the two browsers or the two peers, you can create this data channel

that is just arbitrary data. The interface is the same as the WebSocket interface, so you can just send messages, anything you want. It's encrypted with DTLS, and you can choose if it's reliable or unreliable.

That means it's kind of like TCP or UDP you choose if you want every message, or you can just deal with discarding a few of them. So the signaling, the way to establish the communication between the two peers, you need a way for them to discover each other.

That is called signaling in the WebRTC world. And basically the two browsers will talk to some central server that will help them discover each other. I didn't say that actually the signaling is completely abstract in the way you can exchange them,

so you can use any method you want. This cloud here basically represents you, your signaling system can be, in the case of Beemax I use WebSockets, and then both partners connect to the same server to exchange the signaling. But you can use, I think the GT guys can use HTTP, and then you can just,

there's a lot of other, any transport really. They will exchange the session descriptions through a signaling server, and then they will establish the peer-to-peer connection between them. The thing is that you already have a way to discover the two peers,

but you probably need to go behind through NAT, or probably behind NAT, because you'll be in a private network or something. So there's IC, which is a component also of the part of WebRTC, and basically the two servers discover each other using the STUN protocol,

which helps them, they basically, in the session description there's information about, the STUN address about how they can traverse the NAT from one side to the other. And if that fails, then you can have an optional relay server, that has to be public, so both partners have to be able to breach it,

and then they can basically relay all the packages between them, using the relay server. So what it looks, this is like a traditional, this is how it would work, if the NAT traversal works, they basically do the signaling, and then they just connect through the NAT, each other,

and if you can't connect through the NAT, then what they will do is send all the packages through the terminal server. As I said, by default WebRTC, everything you send through this peer-to-peer channel is encrypted,

it uses SRTP for the video and audio, and then DTLS for the data. And you also have to make sure the signaling is being done through a secure channel as well, and the way you're almost covered. So I'm going to show you quickly how VMAX works.

This is VMAX deployed. So you can log in with your Twitter account, or as a guest, basically it's just like, you don't need an account, you just put a name. I'm connected, so I'm logging in with an account. I will try to call VARISH with his app there.

I'll show you. Well, I can call him. Are you there? Oh, wait. Call VARISH.

There he is. That's VARISH at the human at the back. So this has like a present system that works through the WebRTC, through the WebSocket server. This is server-side. And then once there is a connection, the chat and the video stream are actually peer-to-peer from browser to browser. They don't go through the server.

And then you can also join rooms, and this is kind of like the conferencing system GTE showed, but in a much simpler way. Nice. So basically here everyone is connected to each other.

So each of the participants is connected to each other. There's no central server that is actually relaying everything. The problem with this is that if many people join this, you'll probably crash. There's actually no limitation right now, but you can probably handle like eight participants, no more than that.

I'm going to leave the room. So you can find it. This is the URL. You can go and try it right now. There's a link at the bottom of the page with a GitHub URL if you want to check it out.

This is a stack that VMAX is built on top. It's a socket stream, which is an old framework that allows you to probably subscribe, message passing, etc. And the front and the back end is like really, really small because the only thing it does is just message passing between the WebSocket clients.

Everything else is built on the client side and is built on top of the background. It's written on CoffeeScript. The authentication, I chose Twitter because I use it all the time, but actually it uses every auth, which is a node project that is like pluggable authentication, so you can use anything you want really.

And if you want to start with WordC or try it and start building stuff, there's like really interesting projects. There's a main reference app from Google, which is AppRTC. And they have this really useful adapter.js, which is just a polyfill for like...

Some of the APIs are actually namespaced with the Mozilla, Moz, RTC, etc., or WebKit. And with AppRTC.js you have like a concise way to use it. And Google also has a STUN server that you can use.

You don't have to deploy your own. You can use basically a public STUN server they have available. They don't have any relay server, but it's good. If you want to do some debugging, Chrome comes with WebRTC internals, which is built into the browser,

and it will help you debug everything related with WebRTC. Very detailed information about the connection, etc. And then there are some really cool libraries. You probably know a few of them. A simple WordC is from the guy from Torquayo. And it's a really, really nice library if you want to start building something

on top of a WordC that's like a video base. There's a few links. Sharefest is basically to share files, because you can just establish the data channel without the video and audio stream. So you can use it to share files peer-to-peer in the browser. You can just drag and drop a file into your browser, and it will be sent to the remote peer.

And obviously there are a few resources. I will publish the links to the slides afterwards. That's it. So we have time for some questions.

I see a question at the front. Yeah, you can clone it from GitHub and then just npm start, and it will run.

Oh, he was asking what I showed. It runs locally. You go to GitHub, you clone it, and then the only thing you need is a working node stack, having node in your laptop, and then you just install the dependencies when npm install, and npm start, and you have the same thing running locally. It's super easy to deploy as well.

The only dependency you have is Redis, which is the key value store. It's available everywhere. So that's the only dependency really. We have another question at the rear. Thank you. How do you manage the overwriting when you have more than two or three peers?

Because it seems to be the general problem when you encode and decode video between peers, and everybody has to make this CPU-intensive operation. Yeah. I'm not handling that at all in the application. Basically, what you saw on the conference system

is not handling that at all. It's just basically connecting each peer with each other, and it's not limited. So if you have a fairly powerful laptop, it will work fine. If you have an old laptop, it will probably have some problems. I do have a crappy laptop, and I couldn't go further than four people.

Otherwise, I was burned everywhere. Yeah. You will have to use something like the JITC, probably, where you are just connecting with just one partner that is actually broadcasting to everyone else. There are also commercial solutions, but the JITC one looks awesome.

We have a question. Hi. What about SID RTP, the new standard?

Do you support SID RTP? Not S, but SID. That's part of the WebRTC standard. Right now, the configuration is not specifying anything, so it isn't the default one, but probably it would be just like changing that one year.

With S RTP, you have to interchange the keys, the cool keys, and with SID, they are auto-generated, it's session, so it's more secure. Right. I didn't check it, but I will take a look, and probably I just use that. Timurman, the creator of PGP,

is the one that did this. Right. It's available on Chrome. Sorry? It's available already on Chrome and Firefox. I don't know if it's included in WebRTC, so the question was... No, I don't know. OK. Thanks.

Thank you for your talk.