WebRTC BEP/Connecting the WebRTC Torrent/Standard Torrent Networks/Working with torrents already widely used

[bbarrows]

I should start by saying that I think this is an AWESOME project. That's the reason I am following it and sending you these probably annoying messages. I am currently juggling a few jobs but when I find some time I plan on working on this.

When I was working at BitTorrent and was focusing on coming up with some cool new features I would day dream about the ability to just go to some torrent site, click on the torrent link, and have the site's own JS based client download the torrent without any need of a plugin or any additional work. This would make really lower the barrier for the general population to use torrents. For example, my friends/parents have trouble with the whole two step approach that torrents currently require. Meaning you have to download the torrent file/click the magnet link then use your torrent client to actually download the data. Having a 100% JS Torrent client would allow torrent sites to provide the torrent client ON SITE, removing the need for any extra steps or software.

The real issue as you have pointed out is connecting the two networks.

Who ever made the graphs and wrote the README for this project did an amazing job explaining the need to connect the two "networks" (the WebRTC and conventional torrent network). It is too bad that sites like joker.org get taken down so fast.. (It was posted a week ago https://news.ycombinator.com/item?id=8520954 and is already "looking for a new home") . I would love to bring up a bunch of proxy servers that proxy the WebRTC connections to regular torrent clients but as you said or I think possibly implied the future of a project like this would be based on a large majority of torrent clients implementing WebRTC connections.

Until then maybe an opensource WebRTC Proxy service, made to be easily deployable could be written as a temporary bandaid to the isssue. A temporary/proxy solution like this might actually even help increase the use of WebRTC Torrent clients, encouraging widely used Torrent clients to implement the new protocol/BEP.

However I think, from reading some of your posts that we both believe that a distributed solution is required (people bring up new torrent proxy servers/web apps all the time and they are taken down in days).

@feross I see you wrote http://librelist.com/browser//webp2p/2013/12/8/webtorrent/ which is a great document about the problem. In this document you say a good solution would be a Torrent client that supported both WebRTC and conventional torrenting as a Chrome/Firefox plugin/extension. To help with with I could def. get my buddy Kyle to add WebRTC support to his https://chrome.google.com/webstore/detail/jstorrent/anhdpjpojoipgpmfanmedjghaligalgb?hl=en or add it myself but last I talked to him he has some free time and he LOVES to get feedback and suggestions for new features. If a few people asked for this he would do it (and do it well, super smart, great dev).

I also see you have https://www.bountysource.com/issues/1757063-how-does-webtorrent-work

If I disagree with anything I guess it would be the focus on creating a NEW torrent client, in order to really bring these two networks together I would argue that it would be best to utilize the already wide spread use of popular torrent clients by adding WebRTC support to them. If we/someone could get a pull request accepted into one the bigger torrent clients, enabling WebRTC support the network separation issue would be basically solved IMO (I am sure this would be a huge undertaking and not as simple as I currently imagine but seems like a good solution to me at the time).

So I am assuming Deluge, Transmission, and Azureus/Vuze to be the most widely used Open Source BitTorrent clients in use (could not find any actual number). I will do some research and look into which client would:

A. Be most likely to accept a pull request for a BEP like this.
B. Be most likely to have it be built into the "core" not as some plugin that the user would have to enable (which would most likely mean it would never be used)
C. Be the easiest to work with (programmatically. For ex, Transmission is in C and Azureus is in Java I believe. I would personally be able to write a solution in Java much better.)

So in summary, I personally believe (not that my own opinions really mean much, I am just trying to find a way to help and possibly start a conversation about the best way to get wide spread WebRTC adoption) that your plan for a WebRTC/Standard Torrent client Chrome extension is great but a better approach would be to target torrent clients already in wide spread use. I mean if your going to continue with the Chome Extension plan why not just work with Kyle, send him a pull request, adding WebRTC to his 100% JS Chrome Extension Torrent client which ALREADY has tens of thousands of users. And even thinking bigger, why not target the big Opensource clients you mention in the README? It sounds like your hoping they will add the plugin themselves but it might be better to work with them on adding a WebRTC solution then creating your own "wheel" right? Just my opinion.

I have always wanted to get involved with a good OpenSource project and have always like the idea of connecting WebRTC with the torrent network so would love to be involved and I personally will be looking into a way to add WebRTC to Deluge, Transmission, or Azureus/Vuze. Let me know what you think those ideas, specifically targeting widely used torrent clients instead of creating a new extension.

Thank you!
Brad

[bbarrows]

@yipperr this is also related to the conversation we were having in the other "BEP issue". Maybe you have some input here?

[bbarrows]

@feross Also, I see the travis build uses 0.10.33 . Trying to install with npm 1.2.14 and node v0.10 I get all kinds of failed dependency installs. Im bulding 10.33 right now but I was wondering if there are any dependencies on NPM or anything else U could let me know about to build this project? I would love to try to work on the DHT announce issue for ex. Your code is great. Very readable

[yipperr]

@bbarrows i think the reason a torrent client is being written from scratch is means to get acquainted with the all the implementation detail and have a better flexibility so at least the realization of this between both the webtorrent.js and the node desktop client would be easy as opposed to implementing this in other torrent clients. the only thing i was concerned over the webtorrent client was the choice to release as a nodewebkit based app, i think the chrome app javascript method would attract a way larger audience than the any nodeapp installer for all the platform even though this means to work with the CSP restrictions. all native platform support can be achived with the packaged app (Chrome app) for chrome and the equivalent in firefox
on a side note stuff like nacl with the ppapi and npapi(still supported by firefox) can be used for a torrent client that is as fast any desktop one's out there, so those sha hash verification and everything else will be way faster( my point is if the webmaster wants to notify there userbase to install the webtorrent app to get access to the btswarm a chromeapp from the google app store is risk free and trustable from the end-user point of view as opposed to exe installer for windows to package thewebkit and based app) again i am assuming way too much would like to here everyone thoughts on these also..

sites like joker.com and iflix.io are a joke compared to what this project is trying to achieve all those does p2p on there central server and use the client server model to send data to the user this is idiotic because there inherently holding all the data ( most of them pirated on there servers) and then sending http streams off the server.. this is bad because the server can be penalized for distributing data

[tghosgor]

I think it is much better to have a standalone separate solution to this first. Implementing the new extension to BT protocol with wide-spread support would be long away IMO. I think a browser plugin will be a better and necessary solution for the short-term.

Is there any ongoing browser extension projects to be a shim layer between webtorrent swarm and bittorrent swarm? Also, are there any PR/fork work on libtorrent or such repositories?

[feross]

@bbarrows Sorry for the slow response, I just saw this. Are you still interested in helping WebTorrent?

Getting your friend Kyle to add WebRTC support to JSTorrent would be amazing! I am happy to help out on a PR and finally write up the BEP if there's actually someone else interested in implementing. How can we make this happen? Can you introduce us?

[feross]

@bbarrows I opened an issue on JSTorrent here: kzahel/jstorrent#106

[feross]

Now tracking this in #369