Add WebRTC support to popular torrent clients

[feross]

Meta issue to track progress on getting WebRTC support into popular torrent clients.

• WebTorrent Desktop
• Playback (#329)
• Vuze
• Brave Browser (brave/browser-laptop#3256)
• JSTorrent (kzahel/jstorrent#106, #175)
• libtorrent (arvidn/libtorrent#223, #241)
• libtransmission (transmission/transmission#47)
• rtorrent (rakshasa/rtorrent#717)
• anacrolix/torrent (Go) (anacrolix/torrent#138)

[gauravsaini]

👍

[Stiveknx]

Hi @feross.

So, how is the progress on this?

[feross]

@dcposch has done some exploration of getting webrtc support into libtorrent. It looks like it'll be doable!

[transitive-bullshit]

@feross seems to me that this should be the most important outstanding issue by far as it is really the only blocker for webtorrent gaining widespread use in the browser and fulfilling the original promise of the project.

@feross @mafintosh One other extremely popular torrent client that isn't listed here would be peerflix, as it still sees ridiculous usage (although hard to quantify) via the various popcorn-time forks. If peerflix were augmented to support webrtc peers, that could potentially allow a popcorn-time in the browser use case to function very well. Product Hunters seem to agree that this would be a great development.

It's also pretty clear that given the synergy between torrent-stream/peerflix and webtorrent in terms of environment and shared dependencies, making peerflix peers hybrid wouldn't be nearly as difficult as integrating webrtc support into the other, non-js-based torrent clients.

[dcposch]

Interesting...

peerflix peers hybrid wouldn't be nearly as difficult as integrating webrtc support into the other, non-js-based torrent clients

Agreed. @jhiesey & i checked out how hard it would be to add webtorrent support to one of the native torrent libraries, eg libtorrent.

It looks like the biggest hurdle is that there's no libdatachannel or anything like that, no small library with a clean API for using WebRTC data channels. instead, there are two full WebRTC implementations:

• https://github.com/js-platform/libwebrtc looks pretty tightly coupled to the Chromium build process, and is really complex. In fact, as far as i can tell, they literally pasted in much of the Chromium source code, including parts that have nothing to do with WebRTC. See, for example: https://github.com/js-platform/libwebrtc/tree/master/chromium/src/net/ftp
• https://github.com/EricssonResearch/openwebrtc looks smaller and cleaner, but still has a lot of video & audio handling code which we'd have to remove.

[B00tLdr]

Maybe this project could be helpful: https://github.com/xhs/librtcdc

[dcposch]

wow, that looks awesome. if i have time later i'll try it out

[jhiesey]

@dcposch if it works well I want to look at making node bindings for it as well.

[cathalgarvey]

Sorry if this is a stupid question, but:

Webtorrent's docs/FAQ suggest that browser-based WebTorrent users can only communicate with other browser based clients and "hybrid" clients. "Hybrid" clients can communicate with either pool, bridging the swarms.

Ultimately we don't want bridges, we want one swarm. But right now, what are the "bridges" or "hybrids"? Node-based WebTorrent users? Or something else?

[rom1504]

@cathalgarvey there is a node hybrid client : see https://github.com/feross/webtorrent-hybrid (also see webtorrent/webtorrent-hybrid#5 (comment))

[devlo]

@feross
Did you reach to bittorrent inc ? Making webtorrent as extension to Bittorrent protocol would be huge step.
The most important adopters are uTorrent and libtorrent (rtorrent, deluge etc.), rest really doesn't matter.
Another thing, where is documentation of protocol which webtorrent uses with implementation details ?
This is a must for adoption and I do not see any links in github repo or on webtorrent.io. You need to standardize webtorrent or you will see no adoption at all.
If someone would like to implement it in C/C++ then where he should look ? What if he is not familiar with javascript ?
In my opinion this is the main reason why you do not see any adoption besides people using your own lib.

[transitive-bullshit]

@devlo completely agreed; I know feross is aware of this, but there just hasn't been anyone who's stepped up and been able to make this integration happen. The piece that I'd recommend starting from would be communicating in C from libtorrent to https://github.com/feross/webtorrent-hybrid via webrtc probably using one of the C-based webrtc libraries listed above.

[transitive-bullshit]

See libtorrent#223 for some continued libtorrent discussion.

[rom1504]

https://wiki.vuze.com/w/WebTorrent it seems vuze has support now !

[voxadam]

It seems to me that documenting the protocol adaptations/extensions would be the best way to encourage the developers of other clients to add support to their codebases. Ideally, I suppose this would come in the form of a BEP but even a draft specification would likely be welcomed by many.

[farribeiro]

Add in this issue the link for libtorrent issue on github #223

Duplicated, sorry!

[hex-m]

Someone created a ticket for Transmission. It may need some details though.
transmission/transmission#47

[dessalines]

If this were done for libtorrent, it would work for deluge, and qbittorrent, the two most popular open source bittorrent clients. Once that's done, you instantly got a lot more seeders.

[dessalines]

@feross I'm planning on assisting adding this into libtorrent, with a c++ webRTC library, but could you help point me to which files in this codebase show the webRTC communication?

[yciabaud]

Great @dessalines! Cannot wait to see that coming!

If I can give you some pointers:

1. You will have to connect to the websocket tracker in order to make WebRTC signalling. Basically you will have to add WebRTC offers on announce and manage SDP offers/responses. Here is our implementation: https://github.com/feross/bittorrent-tracker/blob/master/lib/client/websocket-tracker.js
2. Once a WebRTC connexion is established, the torrent peer protocol is used, so there is nothing special here. This project uses https://github.com/feross/simple-peer to make the connexion then it becomes a "normal" peer. (Except that the connexion is handled upstream: https://github.com/feross/webtorrent/blob/15ed59a0d2c9d32598ab4c98706e6fd8fa200843/lib/peer.js#L16)

There is a BEP we are working on in #881, it should give you some informations but be aware that some fields have been renamed for the future standard and read the comments (or look at the code).
The document is published at https://github.com/yciabaud/webtorrent/blob/486a94d2b651e7aed86ba27b82e679f5d1d1e700/bep_webrtc.rst

I am very interested in making libtorrent support webtorrent so ask if there is anything I can do for it.

[fredsif]

Any news about this?
Seems pretty much dead.

[tuxayo]

Here is the issue for rtorrent and libtorrent-rakshasa
rakshasa/rtorrent#717

To avoid confusion, we should also use libtorrent-rasterbar instead of just libtorrent.

https://github.com/rakshasa/rtorrent/wiki#disclaimer

[farribeiro]

@feross add on the list

[Openmedianetwork]

Vuze as a seedbox kind/not works http://hamishcampbell.com/index.php/2018/05/18/testing-peertube-webrtc-seedboxes/

[tuxayo]

From what I understand, as of today there is no client usable on a headless server right?

[cathalgarvey]

Well... Any headless browser. :)

…

On 10 June 2018 19:19:09 GMT+01:00, tuxayo ***@***.***> wrote: From what I understand, as of today there is no client usable on a headless server right? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #369 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rom1504]

webtorrent hybrid

[tuxayo]

Request to add BiglyBT to the list.

It can be seen as the continuation of Vuze as it's development has stalled.
https://sourceforge.net/p/azureus/mailman/azureus-commitlog/
https://www.biglybt.com/
https://github.com/BiglySoftware/BiglyBT/graphs/contributors
https://en.wikipedia.org/wiki/Vuze (search for BiglyBT)

As for WebRTC support, I'm testing it but it seems to have NAT and/or UPnP issues for me. So I can't confirm yet if it's usable.

edit 2018-06-23: I'm not sure that BiglyBT and Vuze can actually seed with WebRTC. I could barely seed when with WebTorrent desktop it seeds most of the time.

[tuxayo]

@rom1504

webtorrent hybrid

Thanks for the heads up, I'll try that :)

[kelna]

Is this dead?

[feross]

Is this dead?

No.

[farribeiro]

And implements webrtc without browser... Its possible?

And this... https://github.com/pion/webrtc and https://github.com/thorst/RTC

[ExE-Boss]

Yes, there’s discussion over at arvidn/libtorrent#223 about existing non‑browser WebRTC implementations and their pros and cons.

The most favourable option currently appears to be @lgrahl’s RAWRTC.

[backkem]

Anyone into Go may be able to pick up anacrolix/torrent#138. pion/webrtc should be in good shape to power a Go implementation.

[dessalines]

Libtorrent (which is written in C++) is the only one that matters. It powers qbittorrent, deluge, transmission, rtorrent.

[ExE-Boss]

rTorrent uses its own BitTorrent implementation, which is also, confusingly, called LibTorrent.

[iagovar]

Any update?

I really want to upload my videos to a seedbox and then stream to peertube, bitchute and web players, but it seems odd to have to do it trough a VPS and a freaking browser open. It's just too much bloat because I need to install X and so on.

I don't trust peertube instances to keep hosting.

[transitive-bullshit]

Really interesting progress on integrating into libtorrent. arvidn/libtorrent#4123

[Allardje]

I really hope this is still on-going. I would love to see something like rTorrent adopting WebRTC support. This will be a game changer. Been following this for a very long time but it seems no new clients added WebRTC for years :(.