
WebTorrent now works in the browser, end-to-end - MzHN
https://twitter.com/feross/status/510443904152653824
======
fragmede
"instant.io: drop a file or files on the browser, it generates a torrent, and
you become the first seeder just send the info hash to a friend and they'll
download the file from you using the bittorrent protocol -- swarming works (so
multiple people can download efficiently)"

[https://botbot.me/freenode/webtorrent/2014-09-11/](https://botbot.me/freenode/webtorrent/2014-09-11/)

(wasn't obvious to me what this was...)

------
patrickaljord
This is a very cool project but it is not compatible with current bittorrent
clients. It uses webrtc for the transport instead of UDP. In order for it to
be compatible with traditional bittorrent clients, those clients would have to
implement communication with webtorrent clients, which hopefully shouldn't be
too hard, still as of now it won't work with current clients. Still very cool
though and I hope traditional clients will implement webtorrent. The other way
to make it work would for browsers to implement UDP which some do such as
chrome but only as chrome apps.

~~~
jacquesm
Could you make a 'bridge' somehow between the two (browser extension?)

~~~
MzHN
> WebTorrent is designed to match the BitTorrent protocol as closely as
> possible, so when the time comes, existing BitTorrent clients can easily add
> WebRTC support and swarm with web-based torrent clients, "bridging" the web
> and non-web worlds. [1]

[1]
[https://news.ycombinator.com/item?id=8280436](https://news.ycombinator.com/item?id=8280436)

------
jacquesm
How hard would it be to make a torrent:// protocol extension that allows web
like content to be stored in torrents? Obviously that would only work for
static content (unless the creation of such torrents could be used to preserve
state) but this seems like an interesting development.

Decentralized hosting of content that can easily be browsed seems like a
useful thing to have.

~~~
sktrdie
In terms of accessing small resources (HTML pages), a client-server setup is
by far faster than a P2P system. The Web is client-server specifically for
this reason. Not to mention that the whole power of a client-server setup is
the ability to have clients alter the state of the server. With a P2P system,
propagating changes and making sure each peer has the correct copy, requires
more time.

Check out this paper to learn more about the Web applied to P2P networks [1].

Li, Ruixuan, et al. "WebPeer: A P2P-based System for Publishing and
Discovering Web Services." [http://www-inf.it-
sudparis.eu/~tata/papiers/sellami/P2P_Disc...](http://www-inf.it-
sudparis.eu/~tata/papiers/sellami/P2P_Discovery/01524435.pdf)

~~~
JulianMorrison
Client-server is faster if the server's upload speed can match the client's
download speed, for all clients. Which implies a large, central server.

~~~
jacquesm
There are other parameters that are useful when evaluating a configuration
besides just speed. Resilience is one of those, as is long term availability.
Torrents seem to do quite well in the resilience department, I'm not sure how
well they do when it comes to long term availability. Maybe someone has
already studied that, it would seem to be the torrent equivalent of 'link
rot', and quite possibly it is very high.

------
abdullahkhalids
Github:
[https://github.com/feross/webtorrent](https://github.com/feross/webtorrent)

~~~
MzHN
Also some further details on the instant.io + whiteboard app

[https://botbot.me/freenode/webtorrent/2014-09-11/](https://botbot.me/freenode/webtorrent/2014-09-11/)

------
the8472
While that's a neat tech toy I don't think the browser is a good platform for
a torrent client.

A significant drawback is that you'll have to keep a tab open for seeding. And
no DHT support either.

BT clients are best operated in a daemon-like fashion with access to system
facilities such as inotify, udp and tcp sockets alike and as something that
does not compete for CPU time/garbage collection/file descriptors/etc.
resources with interactive web browsing.

~~~
VikingCoder
Perhaps you're describing a Browser Extension?

~~~
the8472
What would be the benefit of a native code extension over using a standalone
application with some URL handler / file type integration?

I don't see the advantage of "do it in the browser" here.

~~~
rektide
What would be the benefit of a native application over using a browser
extension?

I don't see the advantage of "do it native" here. Nor do I see the advantage
of doing in the browser. They both seem like perfectly good places to write a
BitTorrent client. And I can certainly imagine some interesting cases where I
would want to allow my site users to send traffic between each other over a
well known, advanced P2P syndication system (rather than cobbling up my own).

~~~
the8472
>They both seem like perfectly good places to write a BitTorrent client.

Except they aren't. Web APIs don't provide the facilities necessary for a
complete bittorrent stack. TCP and UDP sockets are essential (this thing uses
webrtc, so it's not even bittorrent-compliant). Additional facilities like
mmaped files, epoll-based socket IO and inotify make for more efficient
implementations. A good bittorrent client on a gigabit connection can push a
lot of data around, hashcheck it and so on.

Some torrents also have thousands of files open simultaneously, this can push
the number of filehandles the browser process has to keep, possibly
conflicting with other files the browser also wants to open, e.g. its cached
files.

You also need to talk to local network devices (UPnP routers), enumerate
network interfaces to bind ports to the correct one so you can tell other
clients your alternative addresses (this is part of ipv4/ipv6 compatbility)
and a whole bunch of other sort of low-level stuff.

Browsers simply do not provide the same access to system APIs. They are not a
libc-replacement.

~~~
M2Ys4U
>Web APIs don't provide the facilities necessary for a complete bittorrent
stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not
even bittorrent-compliant).

While it's only available to privileged and certified apps, Mozilla's
TCPSocket Web API[0] gives you (unsurprisingly, given the name) raw TCP
sockets.

The W3C also has a TCP and UDP Socket API[1] under development.

Obviously, exposing raw TCP/UDP sockets to the open web is a Bad Idea but Web
Apps are more than that.

[0] [https://developer.mozilla.org/en-
US/docs/Web/API/TCPSocket](https://developer.mozilla.org/en-
US/docs/Web/API/TCPSocket)

[1] [http://www.w3.org/2012/sysapps/tcp-udp-
sockets/](http://www.w3.org/2012/sysapps/tcp-udp-sockets/)

~~~
dragonwriter
Chrome also a set of raw socket API [1] covering UDP, TCP client, and TCP
server sockets.

[1]
[https://developer.chrome.com/apps/app_network](https://developer.chrome.com/apps/app_network)

------
rid
Seems similar to PaddleOver [1] which was developed by Bittorrent inc a few
years ago using their Btapp.js [2] library, unfortunately the PaddleOver site
has expired and the code base hasn't been updated in a year.

It would be interesting to know if the developer looked at btapp.js and if so,
why did he decide not to use it? Getting this technology web embeddable will
go a long way to start making peer-to-peer a convenient method of downloading
content vs directly downloading from a server, there's always going to be
further hurdles to overcome with reliability in a case where the swarm
lifetime is very short, but seeding with a few servers can help in that
situation. If a web app could upload the torrent and data to a server to seed,
then replicate it in a few locations it could be a decent DCDN.

[1] [http://pwmckenna.com/2012/06/29/making-of-paddle-
over.html](http://pwmckenna.com/2012/06/29/making-of-paddle-over.html)

[2] [http://btappjs.com/](http://btappjs.com/)

~~~
Legogris
Btapp.js is just a JavaScript API that acts like an interface to their closed-
source, Windows-and-OSX-only browser plugin Torque:
[https://github.com/bittorrenttorque/btapp/issues/11](https://github.com/bittorrenttorque/btapp/issues/11)

Something that is done purely with cross-browser compatible web technologies
is far more interesting and promising.

~~~
rid
Thanks for the clarification, additionally I could only find a Chrome plugin
for Torque, which should be compatible with other torrent clients out of the
box. However I can definitely see the advantage of using only web
technologies. If anyone's interested I found the paddleover example on github:

[https://github.com/bittorrenttorque/paddleover.com](https://github.com/bittorrenttorque/paddleover.com)

------
stevekl
Does it mean we can finally have web-based popcorn time?

This is REVOLUTIONARY

~~~
woah
Finally someone who gets it. Ideally, one could run YouTube on a $5 DO
droplet.

------
wtracy
This looks fantastic for an idea I've been kicking around: Using BitTorrent as
a way for clients to upload multi-gigabyte files to a website without using
FTP.

The idea is to leverage BitTorrent's robustness in the face of random
disconnections and reconnections as well as the easy-to-use throttling options
that most clients expose.

The server would run a special BitTorrent client that never seeds, to prevent
malicious users from using the server as a gateway to redistribute content.

So, rather than the traditional cloud of people seeding and leeching, the only
participants would be one client seeding, and the server leeching. Once the
transfer completes, the user could disconnect and the torrent would cease to
exist.

~~~
wmf
Sounds more like rsync over WebRTC.

------
diegocr
I can't get it to work, hope this helps:

Firefox 32:

ICE failed, see about:webrtc for more details

Nightly 35a1:

Mandatory/optional in createOffer options is deprecated! Use {} instead (note
the case difference)!

setLocalDescription called without success/failure callbacks. This is
deprecated, and will be an error in the future.

ICE failed, see about:webrtc for more details

this._pc is null bundle.js:25705

Chrome 37:

Uncaught, unspecified "error" event. bundle.js:9134

------
u124556
Is the info hash different from a magnet url? can they be translated from one
to the other?

~~~
finnn
As i understand it, a magnet URL is a way of transferring an infohash as a URL
scheme, so that it works with other programs. For example, the following
magnet URL:

magnet:?xt=urn:btih:e666231c9a34be278f6cfc390099e4084b30e023&dn=The.Giver+2014+720p+REPACK+HDRip.x264+AC3-JYK&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337

contains first the protocol (magnet:) which tells the OS that this is a magnet
URL so give it to some app that can handle that. Since it's in URL form it's
all broken down into & separated key/value pairs, so next part:

xt=urn:btih:e666231c9a34be278f6cfc390099e4084b30e023

is the infohash (actual infohash is e666231c9a34be278f6cfc390099e4084b30e02,
the xt is just the key for that value, urn:btih probably means something,
google it).

The other ones are pretty self-explanatory, the name of the torrent
(presumably so the client can display something pretty before it has
downloaded the metadata) and some trackers

~~~
M2Ys4U
> urn:btih probably means something, google it

It's a Uniform Resource Name (hence "urn"), btih (BitTorrent Info Hash) is the
namespace identifier and the rest is the namespace-specific string, the actual
infohash.

~~~
finnn
Thanks

------
frik
Is the code available on GitHub? I just saw tge demo on my mobile browser.

------
higherpurpose
Why doesn't it work with magnets, too?

------
html5web
Wow!

------
captainmuon
It's nice to see BitTorrent used for file transfers (user to user). Strange
that it is still hard to get files from A to B. You can put them on a
webserver if you have one, or use dropbox, but the download can only start
when the upload is finished. I usually use scp for this, but it only works
when one side is not firewalled, and isn't feasible for non-technical people.
This one could be really useful.

It's sad that BitTorrent is otherwise basically dead (as a way to obtain
content). Where I live (Germany) you often get immediately subpoenaed (or the
German equiv.) if you use it to download something.

~~~
aw3c2
> Where I live (Germany) you often get immediately subpoenaed (or the German
> equiv.) if you use it to download something.

That's absolutely not true. You can use BitTorrent as much as you like, there
is absolutely no danger in doing so. If you commit copyright violations
however, you might get caught regardless of how you did it.

~~~
Ntrails
Out of interest, could a network provider actually tell the difference between
say the data to update warcraft (which at least used to use a torrent style
download), and the data through uTorrent of a textbook, and so on.

~~~
michaelt
It's easy for the hollywood copyright holders to just load the .torrent/magnet
link into a bittorrent client and look at the list of peers.

Now of course, you can make it difficult to join the torrents - for example,
by using private trackers - but that makes it as difficult for me as for the
hollywood copyright holders.

Then just IP address -> Court order -> ISP -> Your home address and send the
threatening letter.

