search

kzahel / jstorrent

JavaScript Torrent Client primarily for ChromeOS and the Chrome Web Store
https://www.jstorrent.com
Other
405 stars 114 forks source link

Add support for WebTorrent #106

Open feross opened 9 years ago

feross commented 9 years ago

Your friend @bbarrows suggested that we get in touch :)

I run the WebTorrent project. We want to make BitTorrent work over WebRTC so that any website can embed a torrent client right into their website! No plugins or extensions, just HTML5 and WebRTC for peer-to-peer transport in the browser. The protocol is exactly the same - we've just made a few changes to support the WebRTC transport (similar to how some clients support uTP in addition to TCP). Website visitors can download to/from other clients that choose to support WebRTC.

@bbarrows and I were hoping that you'd be interested in adding WebRTC support to JSTorrent, so it can peer with other browser-based torrent clients.

You can read more about WebTorrent here: https://github.com/feross/webtorrent There's a live demo here: https://instant.io

If you're interested, I'm happy to help by sending a PR!

kzahel commented 9 years ago

Hi Feross, I agree this would be a great bridge since no other clients have WebRTC enabled (I assume some node.js library provides support but I am not sure how deeply WebRTC is tied into blink and/or chromium...)

Currently JSTorrent doesn't even do seeding because on ChromeOS there is still the firewall, but this is changing soon and this will actually be viable.

Aki11es commented 9 years ago

Following the discussion, with interest!

Feross Aboukhadijeh notifications@github.com wrote:

Your friend @bbarrows suggested that we get in touch :)

I run the WebTorrent project. We want to make BitTorrent work over WebRTC so that any website can embed a torrent client right into their website! No plugins or extensions, just HTML5 and WebRTC for peer-to-peer transport in the browser. The protocol is exactly the same - we've just made a few changes to support the WebRTC transport (similar to how some clients support uTP in addition to TCP). Website visitors can download to/from other clients that choose to support WebRTC.

@bbarrows and I were hoping that you'd be interested in adding WebRTC support to JSTorrent, so it can peer with other browser-based torrent clients.

You can read more about WebTorrent here: https://github.com/feross/webtorrent There's a live demo here: https://instant.io

If you're interested, I'm happy to help by sending a PR!

Reply to this email directly or view it on GitHub: https://github.com/kzahel/jstorrent/issues/106

feross commented 9 years ago

@kzahel

(I assume some node.js library provides support

Yep, there's an npm package wrtc which provides WebRTC support in node.js, but it's difficult to install, doesn't work for windows users, and sometimes starts using 100% CPU for no reason :/

Nonetheless, I wrote a client that uses wrtc and can connect to both networks: webtorrent-hybrid. Eventually, I hope that we can make wrtc more reliable, or just write a datachannel stack in pure JS so we don't need to compile so much of chromium.

feross commented 9 years ago

@kzahel

Currently JSTorrent doesn't even do seeding because on ChromeOS there is still the firewall, but this is changing soon and this will actually be viable.

Nice – this is great news! Is ChromeOS lifting the restriction? In any case, WebRTC can usually get around firewalls because it uses the ICE protocol to punch a hole in most NATs / software firewalls. (For example, Google Hangouts uses WebRTC and works on a Chromebook just fine.) So, as long as JSTorrent implements the seeding logic, it should be possible to drop in WebRTC as a transport and have it work!

kzahel commented 9 years ago

Also on a related note, it would probably be easier for desktop clients such as uTorrent/transmission/etc to support bittorrent over websocket connections. When I was working at BitTorrent there was a flag to enable incoming bittorrent protocol connections using the websocket transport. However it was only ever shipped in beta builds. @prozacchiwawa would probably know the status on that

feross commented 9 years ago

Interesting! The issue with WebSocket connections is that it's not P2P. Some server has to forward all the traffic between peers - which is expensive and carries liability. An installed desktop client could try to start a WebSocket server and have other peers connect to it, but that will only work if that peer has a public IP, or has port forwarding set up, or has no NAT. That's not going to be many peers.

kzahel commented 9 years ago

I don't quite understand. Pretty much all desktop clients are able to do the NAT/uPnP dance and announce IP/port to trackers/DHT where they accept incoming connections. Those clients already do negotiation of which transport they use (protocol encryption vs plain, TCP vs uTP) so that would be a ton of clients. In fact, many, many more than lowly JSTorrent. Think 100 million clients that could accept direct websocket connections, instead of a few hundred or few thousand that JSTorrent has. Not enough to really make a very big difference...

feross commented 9 years ago

Pretty much all desktop clients are able to do the NAT/uPnP dance

You're right. I hadn't even considered this approach before. The nice thing about using WebSockets is that the C and Java libraries that exist are going to be way more lightweight than the webrtc.org library. Right now, there's no data channel only build, so the library is a bit hefty. A WebSocket transport actually makes a lot of sense!

feross commented 9 years ago

That said, we still need WebRTC for browser-to-browser connections, as well as for clients that don't want to support UPnP and NAT-PMP. For example, a native app like Playback would just use WebRTC, since it's based on Electron which is just Chromium, and that comes with WebRTC support.

kzahel commented 9 years ago

The only issue with websocket transport is perhaps cross domain issues. You would not be able to connect to a non-TLS websocket connection (obviously clients would not have valid certs) from an HTTPS page. So http://instant.io would work but https://instant.io would not. WebRTC would not have this drawback

feross commented 9 years ago

Ah, right. Clients would need to present a cert signed by a CA. That sucks...

feross commented 9 years ago

This is an insane idea, but once LetsEncrypt is live, it will be possible to get a free cert. It's possible to issue a cert for an IP address. So, perhaps clients can request a cert from LetsEncrypt via their API in order to support TLS websockets. I'm not sure if they're okay issuing certs to users of IPs rather than the actual owner.

Manouchehri commented 8 years ago

@kzahel I wasn't able to find a lot on Google about using BitTorrent over a WebSocket transport (a lot of results actually linked back here); would you mind pointing me in the right direction?

kzahel commented 8 years ago

@Manouchehri A bittorrent client could have websocket protocol support, in theory. AFAIK, none currently have support for this. The advantage of using websockets over, say XHR, are that you can have bidirectional binary data communication over the single socket connection.

I'm not sure if this is helpful, if you want to contact me directly you can reach me at kyle@graehlarts.com

Manouchehri commented 8 years ago

@kzahel You mentioned that WebSockets support was shipped in a beta build though? That's what I was curious about, because I wasn't able to find any public information on that.

kzahel commented 8 years ago

Yes, I tested with a build of uTorrent with support for this back in around 2013? I don't have the exe around nor do I recall the version number. It was never shipped out into the stable channel.

Manouchehri commented 8 years ago

Ah, thanks; that would explain why I couldn't find it.

Manouchehri commented 8 years ago

@feross Let's Encrypt has heavy rate limiting per domain (10 per week at the moment), so each user would require their own domain name.

https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769

kzahel commented 8 years ago

I recently added UPNP support and am working on improving trackers. I'm thinking about webRTC transport again. Do you have a canonical tracker running somewhere or documents about how for example to advertise to a tracker that we support incoming webrtc connections? e.g. see https://wiki.vuze.com/w/Message_Stream_Encryption (under Tracker Extensions) maybe a query parameter like supportswebrtc=1

feross commented 8 years ago

@kzahel You can see how webtorrent trackers work here:

https://github.com/feross/bittorrent-tracker/blob/master/lib/client/websocket-tracker.js https://github.com/feross/bittorrent-tracker/blob/master/lib/server/parse-websocket.js

kzahel commented 8 years ago

Thanks. Is it OK if I do some testing on wss://tracker.btorrent.xyz/ wss://tracker.webtorrent.io/ ?

feross commented 8 years ago

What do you mean by testing? Sending normal requests to those servers should be fine -- just don't DOS them. ;)

jimmywarting commented 5 years ago

+1

ExE-Boss commented 4 years ago

This should be easy‑ish for JSTorrent to do, since it’s a Chrome app with a helper extension, and as such, already has WebRTC support from Chromium.

w0rp commented 8 months ago

Can anyone here offer any advice on how to complete the integration with WebTorrent and to close this issue? I am willing to do the work myself, or find someone who can do it, provided we have some context and pointers on what challenges we'll face and where to look in the codebase.