Support our Teespring campaign! Get your JavaScript Jabber unisex t-shirts, hoodies, ladies’-sized, and long-sleeve tees!

02:01 - Feross Aboukhadijeh Introduction

02:39 - Peer-to-Peer Background, Content Delivery Networks (CDNs)

09:43 - The BitTorrent Protocol and Hypertext Transfer Protocol (HTTP)

13:08 - WebTorrent = BitTorrent over WebRTC

17:22 - Where Do Original Files Come From?

21:23 - Opposition

27:26 - Where is WebTorrent Going? (Use Cases)

29:52 - Live Broadcasts

31:12 - Progression of BitTorrent Over Time

35:03 - Same-Origin Policy

36:33 - Firefox Hello

Picks

January 12th, 2016: Goodbye IE8 and IE9! (Dave)
 js-must-watch (Aimee)
Headspace (Aimee)
Popcorn Time (AJ)
Steelheart (The Reckoners) by Brandon Sanderson (Chuck)
Teespring (Chuck)
Loop Drop by Matt McKegg (Feross)
SceneVR by Ben Nolan (Feross)
WebTorrent (Feross)
node-nat-upnp (AJ)
node-nat-pmp (AJ)
simple-peer (Feross)

Special Guest: Feross Aboukhadijeh.

 

[Singing]Let’s get it started in here!!

Hey everybody and welcome to episode 155 of the JavaScript Jabber Show. This week on our panel, we have Aimee Knight.

Hello.

AJ O’Neal.

Yo, yo, yo, coming at you live from the secret dark underworld hiding place that you don’t know about.

Dave Smith.

Greetings.

I’m Charles Max Wood from DevChat.tv. And we’ve got a special guest this week. It’s Feross… I’m not even going to try and say his last name.

It’s Aboukhadijeh, but nice try.

Had about the same number of syllables. You want to introduce yourself really quickly?

Sure. So, I’m Feross, and I’m a hacker and I build stuff. And I’m currently in New Zealand with Dominic Tarr and substack. And we’re on a sailboat. And we’re adventuring.

Wait. Are you on a sailboat right now?

Yes, yes actually I am using 3G to talk to you.

Oh wow.

Oh my goodness. This has got to be the greatest thing ever.

I was going to say, that’s got to be a first.

I’ve done a lot of shows. I don’t think I’ve ever talked to anyone on a sailboat.

You definitely got me beaten.

Yeah. I know. I could totally hear AJ. “Yo, yo, yo, coming at you from a yacht.” [Chuckles]

Cool. So, we brought you on today to talk about instant.io and WebTorrent. Do you want to give us a quick overview of what those are?

Yeah, sure. So, maybe I should start with a little bit of background about how I got to WebTorrent as a project. So, I’ve always been interested in hacking stuff, like trying to figure out how stuff really works versus how it’s documented to work. Because when you find differences in how something’s supposed to work and how it actually works, that’s often an opportunity for you to surprise people or to take advantage of the system for your own gain or something like that, which is kind of fun.

So, I used to do lots of shenanigans in college, like different hacks and stuff. So, one fun thing I did was I discovered that the Mac terminals that students did their homework on actually allowed remote ssh one time. So, I remote ssh’d in and turned up the volume on a student’s computer who was sitting a little ways away from me in the library. And then I used the say command on the Mac to talk to them and scared the crap out of them. So I was like, “Hey, stop pressing my keys so hard.”

And then they were like, “What?” And then they turned around and stuff to see what was going on. It was great. So, ever since then I got into that kind of stuff. I was always trying to surprise people with computers.

And so, when I graduated I discovered WebRTC, which was this emerging technology at the time in browsers that lets you do peer-to-peer connections from one browser to another, which was previously not possible. And so, I was like, well what can I build with this? This is a new thing, and there’s going to be lots of new apps built with this. What would be a cool app to build? And the main app that people kept building with WebRTC was video chat, video and voice communication apps. And so, that’s the obvious use case for peer-to-peer because you can improve call quality and basically make the experience a lot better. [Inaudible] because you don’t have to [relay all the] communication to a server. And that reduces latency. And so, there were a lot of apps being built like that.

But I thought it would be cool to use this other part of the spec called the data channel, which lets you send arbitrary data from browser to browser, instead of just video and audio. And with that, you can really go with any kind of app you can think of because you can create your own protocols. So, I started hacking on this thing called PeerCDN which is basically a shared web cache, kind of if you can imagine. So, the idea was that when you came to a site, it would try to see if anyone else who’s currently on the same website as you has some of the resources that you want. So, images, videos, files, to load the site. And if they do, you would connect to them and get the files from them rather than the original server, saving the site owner bandwidth.

That sounds really interesting, just from the standpoint of instead of making a bunch of requests to the server you’re making requests to other people to get the resources.

Yeah. It’s like BitTorrent for websites, basically, to load sites. So, site owners would basically add a script tag to their page that would load up the PeerCDN library. And then that would prevent all of normal resource loading. So, if there were image tags on the page, the script would disable them from loading. And then it would load [inaudible] and would connect to a tracker server, which would say, “Hey, are there any peers who have this image that I want?” And then the tracker would reply with a list of peers to connect to. And then the browser would connect to them and get the file if possible. And then if those peers are being unresponsive or really slow for some reason, there was a timer that would basically say, “Okay, this is taking too long. I’m just going to fetch the file normally.” So, the site will always load. But it will try to do a peer-to-peer if it can. And it can do it with a reasonable performance.

Interesting.

It sounds like probably this was incredibly slow. Was it actually pretty slow or did it come out okay fast?

Yeah, it was pretty slow. So, that’s the downside of peer-to-peer is you always have latency upfront usually when you’re doing peer discovery. So, it was really only useful for video, because with video it’s a big file. And so, the upfront latency doesn’t matter as much. And you can do things to trick the user to not even know that it’s [inaudible] peer-to-peer. So, you can fetch the first 10 seconds of the video from the normal HTTP server and then start fetching the rest of the video file over peer-to-peer. So, by the time that first 10 seconds plays, you’re already connected to some peers and you’re good to go to load the rest over peer-to-peer.

Now, that is very clever. How did that come out in practice?

So, video’s really hard. So, you know video was really the main, the best use case for this. We didn’t do video first because it’s just a lot of stuff to deal with, like codecs and to stream arbitrary data into a video tag, it requires a lot of hacks. And it was just, yeah, it was pretty hard. So, we started with images. And then to make that perform reasonably well we would just load the images that were below the fold on the page. So, far down the page. We would load those over peer-topeer. And then everything above the fold we would load normally. So, the idea being that the user probably won’t scroll down the page for at least five seconds. So, it would perform decently.

Very nice. Did you do anything to prevent evil nodes from serving up naughty images instead of the actual images?

Yeah, so much as I enjoy a good troll, yeah we didn’t want that to happen. We basically did what BitTorrent does which is if you have some trusted person who can tell you the hash of the content that you’re downloading, then you can verify once you actually get the content that it’s what you expected it to be by hashing it and then comparing against the known good hash and that they should match. If they don’t match, you just discard the data and then fetch it again from someone else, or you just fetch it from the server and say, “You know what? This is taking too long. I’m just going to get it from the server.”

So, BitTorrent does that by just embedding the hash of the content in the magnet link that you get when you want to torrent something. And so, this had a similar approach. But we didn’t want to make the people change the way their web server served up their content. What we did was we just ran a service that would sit there and you could trust it. And it would go and get content and hash it for you and then return the hash. So, the script would talk to this service transparently. So, it would be able to get known hashes of any URL on your site and then verify when it got the data from peers that it’s correct.

Super cool. So, did this form the inspiration or the basis for WebTorrent?

Yeah. So, we tried to do this as a company. And basically, we were like, “Oh, Akamai has a huge CDN business. Maybe we can get a cut of their pie and out-innovate them or something.” And so, we built this out. But it turned out it was pretty hard to get customers just because people are really willing to pay for improved performance. They’ll pay you double if you can make their site 20% faster, because they’ve seen all the research that shows that better performance equals more sales. And CDN isn’t that big of a cost for them. Even though as a company Akamai is huge for an individual site, CDN isn’t [inaudible] usually their main cost.

So anyway, people weren’t that excited about saving bandwidth. I was excited because I thought people would build new applications that didn’t exist before. Every time the internet gets faster, people are like, “Oh, it’s already fast enough,” or, “Oh, CPUs don’t need to be any faster.” So I was like, “Okay, well to make bandwidth cheaper, we can build apps that use a lot more of it.” But in the end we sold the company to Yahoo and went and worked there for a while. So, I worked there for a year. And then I’m in New Zealand so I quit my job and I’m ready to do the next thing.

So, do you want to talk a little bit about the BitTorrent protocol so [we can] understand what you built?

Yeah, sure.

Based on your talk, it might be good to compare it with HTTP like you did. And compare and contrast is good because I know a lot of the people I work with, they weren’t really familiar with the protocol at all. So, I think a lot of people probably aren’t.

That’s a good idea. Yeah. I just assumed the people who listen to JavaScript Jabber are uber nerds. But that’s probably not accurate [chuckles]. Okay, so let’s compare BitTorrent to HTTP. So, HTTP is the standard for how we load websites today. And it has a client/server model. So, the client makes the request to the server and the server returns the resource if it has the resource. And this is nice because it’s simple. But it doesn’t scale well when you have a lot of clients all requesting the same resource. Another disadvantage of HTTP is that if the server loses a file or deletes a file, then suddenly all clients can’t find it anymore. And this is because the file is referred to by its location. So, this is why we call them URLs, Uniform Resource Locators.

And so, if the location suddenly goes away, then we have broken links. And this isn’t good. Because the file could exist on another server somewhere and it would be nice if people could just know that this is another place where you could go and get the file. So, that’s another disadvantage. Also, you have the problem that it’s pretty easy to censor things that are on websites, because they’re just at a certain location. So, you could just go and tell that person to stop serving the file and then everyone gets a broken link.

So, BitTorrent on the other hand, it doesn’t refer to files by their location like URLs. Instead you refer to files by their contents, which seems a little weird at first because it’s like, “Well, if you’re going to refer to a file by its contents then wouldn’t you, you basically already have the content. So, why do you need to go get the file?” But what we do is we actually hash the content with a SHA1 hash, which turns this potentially huge file into a nice succinct small little string. And we tell people, this is the file. And so, that’s how you can refer to it.

So, if I wanted to publish a file, in HTTP I would just stick it on a server. But in BitTorrent, what I’ll do is I’ll hash the file then I’ll just give you the hash. And I’ll say, “This is the file.” And then what you do to go get it is you just go out to the whole network and you say, “Hey, does anyone have this file?” And then if you can find people who have it, you request it from them. And then as soon as you get the whole file, you hash what you got and make sure that it matches the hash that you were given. So, that’s really the simplest explanation. It’s actually more complicated. But just to get a rough idea of how it works, I think that’s sufficient.

So, what’s cool about that is that you have, suddenly there’s no server anymore. There are just only clients. Even the person who originally published the file is just a client. There’s no special status for that person. And so, as long as there’s somebody in the world willing to continue to host that file and make it available on their computer, then anyone anywhere else can get it. So, there’s no bottleneck.

And there’s also no single point of failure with regards to scaling, because everyone who’s downloading the file is also uploading the file. So, as soon as I’ve received a few pieces of the file, I can make those available to anyone else even if I don’t have the rest of the file. So, when a file is really popular, everyone who’s downloading becomes really useful to the network because they’re sharing the bits that they have. And suddenly there are many, many, many uploaders of this one file. So, it performs a lot better. And so, it’s pretty elegant, I think. Do you guys have any questions about that?

More specifically, in your talk you talked a lot about the DHT. And I thought that would be good to share, too.

DHT?

Like how it goes about finding the person closest to you for the file.

Oh, yeah. That would be interesting.

Yeah, so okay, I’ll [inaudible] a little bit of that. I don’t want to go too much into how DHT actually works because it’s really hard to understand and I needed pictures to even be able to do that. But I can at least bring up roughly how you find peers.

We might want with, it’s Distributed Hash Table.

Oh, there you go.

What DHT means.

Mm, right, right.

Yes, yes.

Right, right, right. [Laughs] Yeah, we should also get to what WebTorrent is before people get lost on all the details we’re going into. [We just] haven’t talked about what WebTorrent actually is.

You mentioned the way that BitTorrent identifies files. Or rather, they don’t have names. They have hashes, right? So, you said that they use a SHA hash to say, “I want the file that has this SHA hash.” Does that mean that BitTorrent is actually a type of content-addressable file system? Is that a fair thing to say?

Yeah. I don’t know about the file system part. But yeah, certainly content-addressable, because you refer to the content that you want by its hash. That’s correct.

Okay, so is WebTorrent actually using WebRTC to do this? Or is it using some other means?

Yes. So, WebTorrent is just BitTorrent over WebRTC, the idea being, let’s make BitTorrent work in the browser.

Now, does it only connect to other WebTorrent systems or can it connect to other BitTorrent servers as well?

Yeah, that’s a great question. So, right now WebTorrent can only talk to other WebTorrent clients. And that’s because of just how WebRTC works. So, WebRTC is a completely different protocol from TCP and UDP, which are the two other main protocols that run the internet. So, because of security restrictions those aren’t allowed in the browser. But WebRTC is. But it’s so different than those other protocols that there’s really no way to connect from the browser to a BitTorrent client running on someone’s desktop. So, if we ever want to get that to work, the desktop clients will need to add WebRTC as a protocol that they support. So, WebRTC has this weird connection process that’s pretty different than TCP and UDP.

So, TCP and UDP, the way that you connect to somebody is you just know their IP address and their port. And then you can just try to connect to that port. So basically, if you know someone’s address, you can send them mail. That’s how TCP and UDP work. But WebRTC on the other hand requires this weird offer/answer negotiation. So, you have to be introduced to the other peer by a middleman. And then you can establish a direct connection with them. So, they did this for security reasons.

And [inaudible] roughly the way it works is if I want to talk to you, I’ll make an offer which is just a blob of text that has some details about my IP and a shared secret that we’re going to use to encrypt our communication and a few other things. And then I’ll send that to you, usually through a WebSocket server or something. But in theory I can get it to you any way possible. I could text it to you. I could give it to a carrier pigeon or something. And then you get it and then your browser generates an answer from that offer. And then you send the answer back to me. And then once we’ve done that, then we can try to connect directly. So, it’s a bit more elaborate. But once we’re connected then it’s just like any other kind of connection. And we can do whatever protocol we want over it.

And how do you traverse NAT gateways?

So WebRTC actually, the browser actually handles that for you. So, it tries to do this thing called STUNs. I think it’s Session Traversal Utilities, somethings, over NATs I think. Yeah. And yeah, so it has this standard set of hacks that it tries to use to get through NATs. And worst case, if that fails, you can specify a TURN server which is a relay server that will relay all of your traffic. So, if you can’t directly connect to them but you can both connect to this server out there on the internet, then that server can just relay your messages. And at that point it’s basically acting like a WebSocket server or something. So, it’s not ideal. It’s not peer-to-peer and it’s probably pretty expensive to run one of those. But that’s what you can do if you really, really must guarantee 100% reliability on your service that you’re building. So, you’ll see this used on pretty much all of the video and voice apps that are built on top of WebRTC.

So, one thing that I’m wondering about is, how do the original files get up there in the first place? Do you just add them to your WebTorrent server and then other people can get them that way?

No. So, WebTorrent is just a script. It’s just a client that is running in a webpage. So, if you want to get a file into the WebTorrent network to share it, then what we do is we just, there’s this API that the script exposes. And it has a download function and a seed function. So, you just pass the file into seed and then the client will send a message up to a tracker server which just keeps track of all the peers that are interested in certain files. But it refers those files by their hashes. So, the server doesn’t really know what it’s doing. It just keeps a key/value mapping from hash to array of peers. And then when other people want that file, they just talk to the tracker and ask it for any peers that have that file. Then they try to directly connect.

So, it’s just like, that’s actually exactly how BitTorrent works. There are tracker servers which do this coordination of peers. And then there’s this other thing called the Distributed Hash Table or the DHT which allows you to get rid of the tracker and just have the peers out in the world be the tracker. And so, they each take on a bit of responsibility for the torrents that they’re going to track. But that’s, we’re getting into really complicated territory now. [Chuckles]

But all this is to say that if you have a tracker like a generic BitTorrent tracker, it won’t work with WebTorrent. You have to have a WebTorrent-specific tracker, right?

Yeah. So, yeah, there are a few places where I had to change the BitTorrent protocol. But I try to keep the number of those changes as minimal as possible, just because BitTorrent is wellunderstood. It’s one of the most widely deployed peer-to-peer protocols out there. At peak hours, there are 20 million nodes online. It’s just huge and it works. And it’s well-tested. So, I didn’t want to reinvent the wheel and try to be all innovative and rename things for its own sake. So, it’s basically just BitTorrent with a few changes to make it work over WebRTC. And those changes do make it incompatible unfortunately. But those are just required because we have to. The whole point of WebTorrent is to make it work in the browser without any install, without a plugin, without a Chrome Extension. It’s just JavaScript. So, it can run on any page.

So yes, that’s basically, that’s what we had to do. But because it’s following the BitTorrent protocol

as much as possible, it should be pretty easy for desktop clients to add support for WebTorrent. And the BitTorrent community has a long tradition of enhancing the protocol over time. And they do it with this process called a BEP or a BitTorrent Extension Proposal. And you just post up a spec and say, “Hey, I think we should do this.” And then if people like it, they implement it. So, I have faith that this will get implemented by a few of the clients out there. And I have backup plans for what to do if no one wants to implement it also.

Ooh, what’s that? Does it involve escaping on a sailboat? [Laughter]

Sailboat.js?

Yeah, I don’t want to escape on any sailboats or be running from the law or anything like that. But what I want to do is just make it…

I want the Node client already.

Yeah. There is a Node client. Yes, exactly.

Well, you’re going to bridge the gap with the Node client at some point. The readme still says you haven’t done it yet, right?

Yeah. It’s on my laptop. I’m working on it right now. So, it’s almost done. It’s very close. So, basically the idea is… so, WebTorrent has a Node client version and Node clients can talk to all types of peers. It can talk to normal BitTorrent ones and it can talk to the web ones because it includes WebRTC in it. So, if you’re using that and you’re downloading or you’re seeding some content and you’re doing it to both networks, it means you’re helping the web peers.

And so, the plan is basically to take that Node client and bundle it up into a nice, pretty desktop app using Node-Webkit or something like that, and then to offer that up to people to use as their BitTorrent client. So, if people adopt that, if a small percentage of people adopt that, then I think that the two networks will effectively be bridged in that those nodes will act as a bridge between the web and the old way.

So, BitTorrent being the controversial topic that it is, I’m sure that the answer to this question is yes, but is anyone opposing you to make BitTorrent so easily accessible in the browser?

Not really. I haven’t really been opposed [chuckles] or anything. The way I think about what I’m doing is I’m just building, I’m just making a protocol and I’m just implementing a browser for that protocol, basically. So, I don’t know. Maybe if it gets really popular some people won’t be happy with me. But I’m just making a protocol. So, it’s as if somebody got really mad at… if someone’s like, “Oh, this website. I don’t like the contents of this website. Let’s get really mad at the guy who made HTTP, or the committee that made HTTP.” It doesn’t really make sense.

So, that’s something, just a little rant. I just don’t understand. It seems like BitTorrent is the solution to so many problems. And leaders in the industry just want to oppose it instead of embracing and be like, “Wow. This is a new way forward. This is a new way to reach new markets. This is a new way to use products and create products and distribute products.” They’re like, “Eeh. It’s cool. So, we hate it and we’re just going to…”

Hm.

“Get mad because popcorn time. Ra!” [Chuckles]

Well, most of the time when I hear people object to BitTorrent, what they’re really objecting to is the way that people use it to share copyrighted information. So, when they object to it, they’re basically objecting to people putting movies and TV shows that are copyrighted on there. And the people doing that are effectively breaking the law by sharing copyrighted material without a license to do so. So, what happens then is they paint the protocol with the brush of the copyright infringement where in reality, BitTorrent is just the means by which people are doing it and not actually… it’s not the problem in and of itself. It’s just a convenient way for people to get around the copyright or to get around the copy protection that’s on the media.

But yeah, I agree with you. Overall, I think it’s a really elegant way to solve problems of getting files around. And I could see applications in doing online backup or sharing your… effectively doing what Dropbox does, right? So, you allow certain people to access the distributed hash tables that contain the hashes of your files and things like that. But yeah, overall I see why they attack it. But I think it’s mostly out of ignorance. They just don’t understand or they don’t care that in fact the protocol is useful.

You know, in terms of usefulness and then… even what they’re attacking, it’s like when the New York Times had to transition over to the internet. Well, they hated it because it disrupts their business model. But hey, you got to move forward and you got to learn to make money with a new business model, right? I think it was Isaac that posted on Twitter a couple of weeks ago a picture of a movie that he had purchased, downloading in iTunes, and it said one hour remaining or something like that. And so then, he opens it up in BitTorrent and it says five minutes remaining. And so, it’s like people use BitTorrent not necessarily for movies, not necessarily because they’re opposed to purchasing but because the purchasing process is terrible.

Yeah. I’ve actually heard that complaint from people while I’ve been here in New Zealand, because New Zealand gets neglected by the movie and music companies. I think Australia finally is getting Netflix. But New Zealand still doesn’t have it. So, they’re forced to use VPNs to pretend that they’re from the US. But then Netflix is now…

Oh my gosh.

Blocking VPNs.

That’s terrible.

So, basically they don’t have Netflix here and they would love to pay for it. But the way that the licensing deals work, they’re region-restricted and stuff. So, I’ve heard that complaint a lot just from talking to people. But I don’t like to focus on that use of BitTorrent because I don’t really condone software piracy and movie and music piracy. And I don’t support it. But the thing is that the protocol is just beautiful. You can transfer files so efficiently. And I think there’s a lot of other interesting use cases for it. There are actually already a lot of people using BitTorrent today to do interesting things. So, for a while Spotify was using it to transfer music between subscribers of the Spotify service. So, I think they actually published a paper saying they saved 82% on their bandwidth costs by using effectively BitTorrent inside of Spotify.

And there’s also…

And I bet a lot of people don’t know that.

I was going to say the Raspberry Pi Foundation, all of their downloads, and most Linux distributions, their downloads are in BitTorrent, because it’s free software. The server cost is pretty high to be downloading gigabytes of stuff.

Mmhmm. Also…

Well, people get it faster, too. It’s a better experience all around.

Yeah, and also Facebook and Twitter are using BitTorrent in their server deployments. Because it turns out if you’re trying to, if you send your code over to a build server and then the server builds it, you get this big compiled binary that you’re going to run on your server. Because that’s how Facebook does their apps now, they compile their PHP into a Linux binary that they can just execute. And then you want to get that out to all of your servers. If that one server has to send it to multiple machines, then it gets bogged down. But if you turn all the servers into a BitTorrent swarm, then they get the content way faster and then they can basically, updates to running servers goes way faster. So, Twitter and Facebook are both using this.

Also, Blizzard and a company… so Blizzard makes World of Warcraft and StarCraft II and a bunch of other games. And the company that does Eve Online, both of those guys are actually using BitTorrent for game updates. So, when the new update comes out, their server normally just gets hammered and no one can get the update and play. But by using BitTorrent it’s really easy.

So, where do you…

See, that’s what I’m talking about. That’s the advancement that I like to see, is when people are using… it’s commercial products. It’s legal. But they’re still distributing it using the good technology instead of trying to ban it.

Exactly.

So, what I’m curious about is where do you see WebTorrent going? So, the file sharing is all pretty convenient. But doing it through the browser is less so, especially getting it onto my, I want to get it onto my hard drive, this that and the other, as opposed to loading it in as part of the page.

Obviously, Facebook’s going to change their deploy to use Chrome with WebTorrent to pull in all their code, right?

[Laughs] I don’t think so. I think the endgame for WebTorrent is someone should use it to build a peer-to-peer YouTube. So, the idea being that when you want to send a video to somebody, you can just send them a link to a page. And then it’ll just play in the page like YouTube, but using WebTorrent under the hood.

Yeah, that would be cool.

And another use case for WebTorrent that’s actually already, that already works today is instant.io. So, instant.io is just a basic WebTorrent client. The UI on it isn’t really good, at least right now. But the idea is you can send files to your friend. And right now Dropbox is used for this. But I didn’t like it for a few reasons, because you have to upload the file fully to their servers before the other person on the other end can start to download it. And sometimes their servers are pretty slow. And you’re just sitting right next to your friend in the same room. So, it should in theory be able to just go over the local network and not go all the way out to Dropbox and back to your friend. So, with WebRTC it tries to find the optimal route to the other peer. So, if you’re on the same network it will directly connect over the local network. And you’ll have super-fast speeds.

So, I built instant.io. And with that you can just drop some files onto your browser and then it will create a torrent in the page, give you the hash of it or a link if you want, and you send that to your friend. They open the link up then they try to find peers who have that content. It turns out it’s just you, since you just created it. It connects to you and then just starts fetching all the content over [inaudible]. And then it loads it right up in their browser. And if it’s streamable content like a video or audio, it’ll just start to play it right away. So, I can send a 10-minute video to you and you can start to watch it immediately, no waiting for it to fully upload anywhere. You play it back as you get it.

What about…

And seeking works, too. So, if you seek to the middle of the video, then WebTorrent will reprioritize the pieces that you’re interested in and it will start to ask for those. So, even seeking around in the video will just work. It’s pretty magical the first time you see it.

So, what about live broadcasts. Have you given any thought to that with WebTorrent?

Yeah, everyone always asks about that. But, so I think you could build something on top of WebTorrent and it does live stuff. But by default, the way BitTorrent works is that you have to know the hash of the content that you’re trying to get in advance so that you can verify that when you get the content that it’s actually correct. So basically, torrents are immutable. You can’t… A live broadcast, the content is constantly coming out. It’s not done yet. And so, you could [maybe] build something on top of WebTorrent or BitTorrent that would do live stuff. But by default, it doesn’t do that. So, what you might be able to do is just turn every 10 seconds of video into its own torrent and then post the hash onto a server somewhere. And then all the people who are watching the livestream could go and get those hashes. And so, they’d be 10 or 20 seconds behind. But it would work. So, [inaudible] it could certainly work. But it’s not in scope for WebTorrent.

Right. So, you basically chunk it up and then you have a library that grabs the next chunk when you’re done with the chunk you’re on.

Right, yeah. It’s always important to know what the hash of the content is so that you know what to expect and you can just, you know when you have a bad peer who’s trying to send you some garbage data or something. So, you reject it.

So, Dave was just posting if I had other questions since I had watched the talk. And since it’s hard to talk without the diagrams, I don’t know if this is good to touch on. But the main takeaway I really got from it was how it makes everything decentralized. So, I’d be curious. In your talk you had mentioned you have to have a tracker to start with. But you said that some people were looking at options to not use that. And I’m just curious what those options are that they were looking into. You just said so, that you didn’t see any good solutions out there yet. But I was curious what those solutions were, or what you think would be possible in the future.

Yeah, so I think what you’re referring to is [inaudible] a little bit about progression of BitTorrent over time.

Yes.

It’s evolved quite a bit since it first came out. So, at first BitTorrent was basically all about making file delivery decentralized. So, going from a single server model to a model where everyone is the server, everyone is just an equal client in the network. But to actually find peers to talk to, to find who has the file, that was still centralized. So, at first that was fine because everyone was just like, “Wow, it’s so cool. We can get files from all these people. The file distribution is the most expensive of the transferring anyway, so who cares if to get peers you need to actually talk to a server, a central server?”

Mmhmm.

But then the community, and probably just because of legal pressure and stuff, they decided to find ways to not have to run tracker servers.

Yes, exactly.

So, they came up with this thing called the Distributed Hash Table. And then effectively it turns every client into a mini tracker. So, everyone just decides to provide that service to the network for a certain portion of all torrents. And so, the way that a client determines which torrents it’s going to be responsible for tracking is by just looking at the hashes of those torrents. And then it compares them to its own identifier that it uses for itself. And then just has, it’s just like how close is that to me? So, every client has its own, an ID. And it’s in the same ID space as the hashes of the content.

And so, you can just basically compare and be like, “Oh, this is close to my ID. Okay, I guess I’ll track that for you.” Or, “Oh, that’s really far away. No, that’s not my job. Go ask someone else to track that for you.” And then there’s this elaborate structure you can build on top of this that lets you find who is tracking the torrent that you’re interested in. But it’s hard to describe. So, if you’re interested I’d just suggest watching the talk at JSConf.Asia where I go into how that works and I show pictures and stuff.

But it’s really cool, actually. It’s one of the coolest ideas in computer science, [I think]. [To think] that you can distribute a key/value store across all these machines and then be able to find who is storing the values for the key that you’re interested in and how to find them and how to do that efficiently without just asking everybody, it’s really cool. But it’s hard to describe without pictures, I think.

Awesome.

Oh, oh, there’s one other thing we should talk about. I just thought…

Okay.

One more thing.

Yeah.

Now it runs on the Apple Watch. [Laughter]

I was thinking that back when he said, “It’s magic.”

[Chuckles] Yeah. Have you seen those compilation videos of all the times that Steve Jobs used to use superlatives when talking about the latest Apple product?

[Laughs] No, I haven’t.

It’s just like, “Super, super great. Amazing. Magical. Magical.”

“Incredible. Intuitive.”

[Laughs] Sailboats.

Someone just sliced out all the bits and put them together.

Intuitive is now a superlative?

I guess. Yeah, I guess it’s not. [Inaudible]

Intuitively.

I don’t know. [Laughter]

So, what was your one more thing moment besides the Apple Watch announcement?

Oh, so one other thing that I think is really cool with WebTorrent is since it uses WebRTC, WebRTC has no notion of same origin policy. So, any WebRTC code running on one domain can talk to any on another domain. And the reason why this is secure is because you have to do that offer/answer exchange which means that both pages, both sides are clearly opting to use this communication because they’re both talking to some service. And that service is passing those offers and answers back and forth and introducing those browsers to each other.

So, there’s no same origin policy, which means the implication for video and voice chat is that I could have a widget on my website and I could talk to users on a different domain who are using a

different service as long as our two services agree to pass these offers and answers back and forth. Which I think is super cool, because it reminds me of chat federation kind of. Or you remember how in the 90s and stuff how you could use, or maybe it was the early 2000s, you could use a single IM client and it would connect to all the different networks? Or you could use…

Oh yeah, Trillian.

Yeah. And their protocols are open so you could write your own AOL Instant Messenger client or whatever. And so, WebRTC is like that. So, if someone’s running WebTorrent on one site and someone is downloading a picture over WebTorrent. And another person on another domain wants to get that same picture, well they can connect to that user on the other domain and get it from them, which I just think is insanely cool.

Have you seen Firefox Hello?

Yeah. That’s the built-in video chat thing in Firefox, right?

Yeah. It’s basically Skype except they don’t have a text chat window yet. It’s just a video chat.

But it’s over WebRTC, right?

Yeah. And you can share a link with anyone. If one person has Firefox, then anybody in any browser can connect to that person. But Firefox I guess has more APIs implemented. So, they can host the session or something. I don’t know if you can visit it or you can host from other browsers yet.

Yeah, so Firefox, yeah they’re just basically, Firefox Hello is just, it’s basically the ‘hello world’ of WebRTC apps. It’s just a video chat app. [Chuckles] But it’s blowing people’s minds because it’s just built into Firefox and it’s just free and easy to use. But, oh yeah, the other thing to know is it only works in certain browsers. So, WebRTC is only available right now in Firefox and Chrome and Opera. And Microsoft announced that they want to support it. But they haven’t said when they’re going to release a browser that supports it. But they’re working on the spec. They’re on the committee that’s working on the spec. So, I’m optimistic that IE will get it. The only browser vendor who hasn’t said anything yet about WebRTC is Apple.

Hmm.

But they have pretty low market share on the desktop anyway. So, it doesn’t really matter, I think. And if you want to do a mobile app on iOS that does WebRTC then you can, well you can just compile WebRTC into your native app and that’s a good hack for now until the browser gets support for it. So, you can just release an app.

Does Chrome on Android support WebRTC?

Yes, it does. And it’s really cool.

So, I take it you’ve had WebTorrent working on it.

Yeah. You can… And so, your Firefox Hello example, you could start a video chat on you Firefox, on your desktop or something, and then send a link to some dude running Android, in Chrome on Android, and then you could video chat with them.

Really cool.

Nice. Alright, well let’s do us some picks. AJ, I always pick you first so I’m going to make Dave go first. [Laughter]

Alright. I have one pick for you. And today’s pick will be a little bit unorthodox. I am going to pick a day of the year. The date is January 12th 2016. Does anybody know why this date is significant?

It’s not Pi Day. [Chuckles]

No. This date is the date that Microsoft has announced that they will no longer support any browser on any operating system that is not the most recent up-to-date available browser for that operating system. Most importantly, this is the date in my opinion that you can actually say, “We will no longer support IE8 or IE9.” And anyway, I think we should start planning parties now.

And then when the date gets closer and Microsoft pushes it back, we’ll have to push our parties back. But at least we can start planning it.

Yeah, I’d say send me an invite, please. You can add me on any of the social networks and I will accept.

I’ll send you a Firefox Hello link.

There you go.

That would be amazing. By that time though, probably a scheduled broadcast…

It’s interesting that Microsoft picked that day. I think that date is the day that the new president gets inaugurated in the US. Isn’t it?

Oh.

It’s pretty close to it.

Interesting. They’re trying to steal some news, some headlines.

Or maybe they’re trying to slide under the radar.

No, we’re not having an election this year, are we? It’s next year.

Oh yeah, that’s 2017. You’re getting ahead of yourself. [Chuckles] That’s what happens when you’re…

Oh, you’re right.

In New Zealand on a sailboat in the middle of the ocean.

You’re right, yeah. It’s January 2017, yeah. [Chuckles]

Pretty sure I’ve heard seagulls twice on the call. [Laughter]

Right. So, what you’re really saying is that when they actually implement that, then yeah it would be about the same time. So, cool. Aimee, do you have some picks for us?

I do. The first one is a link to a GitHub page with a bunch of JavaScript videos. So, you can do a pull request and add to there or just watch the ones that are there.

And the second one is I’ve been using the Headspace app for mindfulness and meditation. I really like it. So, that is my second pick. And that’s it.

Awesome. AJ, you got a pick for us?

Yeah. I’m going to pick popcorn time [laughs] ironically. And I won’t tell you why. And if you want to find out you can just figure it out. I’ll keep myself legally un… I’m in my cave anyway. It doesn’t matter.

Let’s see, other than that. I’ve not been good on picks the past month. I got to think of something good but I don’t have anything good, still. You know what? I pick antisocial-ness. Because you can just be in your cave and code and have no idea what’s going on and just listen to your headphones and code.

I also pick sleep, because I haven’t gotten any in a while. And I’d really like to get reacquainted because I know it’s awesome.

Nice. Alright, I’m going to pick a book. It’s called ‘Steelheart’ by Brandon Sanderson. ‘Steelheart’ is, I’m really enjoying it. I’m not sure why I hadn’t run across this particular series. I’m really enjoying it. So, I’m going to pick that.

And then, oh I’m going to pick Teespring, Teespring.com, which is where we’ve put up the t-shirt campaign. So, if you want JavaScript Jabber shirts, that is the place to go, and it’ll be up for the next couple of weeks. So, make sure you get in there before the campaign ends. Because otherwise, you won’t be able to get them until we do another campaign.

Hey Chuck, did we settle on the giant picture of your face on the front of the shirt?

I think we were going to put that on the back.

[Laughs] I thought that was the back of your head on the back of the shirt and the front of your face on the front of it.

I should totally make some of those.

[Chuckles] The Chuck shirt.

Yeah. Alright, well those are all the picks I’ve got. Feross, do you have a pick for us, some picks for us?

Yeah. So, while I was here in New Zealand I went over to Christchurch for NodeConf Christchurch. And I met some cool people there. And I want to plug a couple of their projects. So, I met this guy Matt McKegg who built this really cool music app using the Web Audio API that he deejays using. And you can make really cool music. And he’s been working on it for two years and it’s a work of art. The music he was making with it was just, I was like, “Wow. This is the first Web Audio thing I’ve heard that sounds really good. It sounds like music. It doesn’t just sound like a demo app.” And I don’t think anyone really knows about his app yet because he hasn’t marketed it at all. But it’s called Loop Drop. And his name is Matt McKegg. So, check it out if you’re interested in music at all and music creation.

And the other project is by Ben Nolan. He created this thing called SceneVR which is… actually I haven’t really read the GitHub page for it yet. But he showed it to me on his phone. And it’s like the Metaverse. It’s like Second Life kind of, but all in the browser, in WebGL. And you just go to a URL and you’re just dropped into this universe that he’s built. And it’s really easy to specify new objects that you want to create in the world using something like HTML. And it’s just really exciting because I think there’s going to be cool use cases for hanging out with people in this world and talking to people.

And he said one way that he uses it that’s cool is he has a virtual office in SceneVR. And he has two computers. So, whenever… he has one that’s in SceneVR at all times. And so, whenever he’s working doing real work on his other computer he just parks himself at his desk in the virtual world. And so, when people come over to talk to him, they know that they’re interrupting him from work. So then, if it’s important he’ll just go over to the other computer and then go talk to them or do whatever he needs to do in the world and then come back to his desk and sit there when he needs to do work. And it’s also cool because you can see how busy somebody is, how many people are vying for their time by seeing how many are literally lined up there to talk to them. Whereas if in email, you just send somebody an email and you don’t really know that. I just thought it was cool. So, it’s SceneVR and his name’s Ben Nolan. And of course, I should…

That sounds really cool.

Of course I should also plug WebTorrent. So, if you want to learn more about that just visit WebTorrent.io.

Oh hey, I totally forgot. There were two things that I wanted to pick that I actually put in the notes already, if I can butt in for two seconds – nat-upnp and nat-pmp node modules so that if you want to do peer-to-peer stuff from home, you can. That was all.

Oh, I should also plug something else [laughs] while we’re all piling on here. I wrote a module called simple-peer, simple dash peer. You can get it on npm. And it makes working with WebRTC really easy because it’s normally pretty complicated. There’s a lot of API calls and you have to do them all in the right order. And it’s a necessary complexity but it’s just too much I think for a lot of people that are just approaching it for the first time. So, simple-peer is like a jQuery for WebRTC. It makes it really simple to use. So, just check that out. It just makes the API really, really easy to get started with and makes it more approachable and less intimidating.

Alright. Well, thanks everyone for coming. It was really interesting to talk through. And it’s definitely on my list of JavaScript projects to just browse through. So, we’ll go ahead and wrap up. Go get you some t-shirts. And we’ll catch you all next week.