Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebTorrent now works in the browser, end-to-end

twitter.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: WebTorrent now works in the browser, end-to-end

#61

Post by rektide »

the8472 wrote: post #54
VikingCoder wrote: post #51

Earlier quoted context omitted.

Perhaps you're describing a Browser Extension?

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.

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).

Re: WebTorrent now works in the browser, end-to-end

#62

Post by michaelt »

Ntrails wrote: post #34
aw3c2 wrote: post #10

Earlier quoted context omitted.

> 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.

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.

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.

Re: WebTorrent now works in the browser, end-to-end

#63

Post by api »

rakoo wrote: post #40
patrickaljord wrote: post #12

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 c…

Nitpick: traditional bittorrent sits on top of TCP. utp, the protocol to make torrents run smoother, does run on UDP, but it's not the official way to do it (although most clients should do it)

uTP isn't really to make torrents run smoother. It's to allow NAT traversal.

Re: WebTorrent now works in the browser, end-to-end

#64

Post by daveloyall »

sktrdie wrote: post #20
jacquesm wrote: post #17

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.

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 l…

If P2P were a "first-class citizen", the initial handshake wouldn't take longer--it would be faster!

Suppose that my city's newspaper (or TV station) monitored the (socially accepted, widely adopted) P2P networks for reliable mirrors of their own content, then sent each user's browser hrefs to the mirrors, rather than their own site.

The more popular the content, the more likely that your next door neighbor's P2P system can stream it to you.

Since running such software is socially acceptable in this hypothetical future, your P2P software doesn't have to go through the 'discovery' step. One of your hostnames is 1234.main.st.ci.lincoln.ne.us (see http://owen.sj.ca.us/~rk/howto/usdomainname.html) and one of them is mirror5.journalstar.org.ci.lincoln.ne.us. Everybody on Main St already knows your IP address, and if you mirror a lot of content, they might even have an existing active connection... you see where this is going? :)

Re: WebTorrent now works in the browser, end-to-end

#67

Post by finnn »

u124556 wrote: post #66

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

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

Re: WebTorrent now works in the browser, end-to-end

#68

Post by solnyshok »

dewey wrote: post #33
captainmuon wrote: post #5

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…

> 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. That's just plain wrong. Maybe if you are downloading the latest hollywood flick from TPB you'll get a "Abmahnung" but that's about it. It's nowhere near "dead". If you are not using one of the big public trackers y…

do they attack you for using btsync between your own PCs?

Re: WebTorrent now works in the browser, end-to-end

#69

Post by the8472 »

rektide wrote: post #61
the8472 wrote: post #54

Earlier quoted context omitted.

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.

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 synd…

>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.

Re: WebTorrent now works in the browser, end-to-end

#70

Post by the8472 »

VikingCoder wrote: post #57
the8472 wrote: post #54

Earlier quoted context omitted.

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.

It doesn't need to be a native code extension; that's not what I'm talking about. In Chrome, you can write browser extensions that are essentially off-screen web pages (in simple HTML and JS). Two advantages of "do it in the browser" are, in theory it would run on every platform that browser is installed on with no additional run-time required (like Python or Java), and two, it could run on Chromebooks. Say, in Incog…

But in case of a browser-extension you just substitute "python" with "chrome" as a runtime.
Post reply on HN