Hacker News Reader

Comment by jiggy2011 | Hacker News Reader

jiggy2011

I never understood why torrent clients are not built into browsers and the defacto means of download. Would be huge cost savings.

View on HN

Opera has (had?) one built in. The difficulty is the necessity of hashing the entire file. Torrents are great for snapshots of large files.

I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.

Or perhaps it is because there is a certain stigma attached to using a technology that enables distribution of data, even when it is against the wishes of the creator of the data.

> I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.

That's self-fulfilling - if it were built into the browser, there's no reason you'd really have to know.

(Presumably you wouldn't run into the "zero-seeders" problem if the servers acted as seeders - they're currently serving 100% of the file anyway (without torrenting), so torrenting would only reduce that.)

Note to anyone planning on using Opera's client: it's terrible, out of spec, and banned on many bittorrent sites.

I don't think the complexity and user experience issues are completely intrinsic to the protocol - BitTornado (sadly, another client that misbehaves, and hasn't been updated in 6 years) was hands-down the easiest for less techy people to use and understand. (Each download has its own window and instance of the program, making it look and feel very similar to downloading in Internet Explorer)

Why do you say the difficulty is in hashing the entire file? BitTorrent divides the files into small chunks and hashes those, so downloading lots of small files vs downloading one big one doesn't make a lot of difference

(with a few caveats - some clients support an additional hash on each file, which can save you re-downloading data if two files share a block and only one is changed, and some clients add padding data so there is only one file per block. In practice, these are both very rare)

I'm not sure it would be so much a net gain in cost savings so much as moving those costs around to the users and local ISPs who'd upstream traffic would increase. Personally I'd rather the content providers eat those costs.

I remember reading about a P2P API inside Chrome, but that may have been just an experimental mode for WebRTC at the time. Having a built-in bittorrent technology would be a big addition to browsers, especially if they intend to use the technology for broadcasts to a lot of people in the future through WebRTC.

It seems like in about 6 months or so (crystal ball reading) this will be available in chrome stable. (createDataChannel is not yet implemented even in Chromium trunk)

It's already possible to participate in BitTorrent swarms in pure javascript with only websockets and typed arrays. (https://github.com/kzahel/jstorrent) It of course requires that BitTorrent clients know how to accept websocket connections and use websocket frames to emulate raw socket data (which is not yet the case, but very well could be)

BitTorrent is associated almost exclusively with piracy, and the protocol is actively blocked on many networks.

It also chokes networks - an open seeding torrent client significantly increases latency, even with the number of connections limited.

It's a problem we have in my house with Spotify, which utilises P2P to lower costs - it has a negative effect on anyone else who is gaming.

Doesn't qos alleviate that, though?

Check out Torque, tiny torrent client in the browser written in Javascript:

https://github.com/bittorrenttorque/btapp

It's actually not written in the browser. It's a javascript API that interfaces with a headless local process (communicating with AJAX over 127.0.0.1. It has issues with mixed secure-content warnings, though)

Reply on news.ycombinator.com