Btapp.js: BitTorrent in the browser | Hacker News Reader

Btapp.js: BitTorrent in the browser

btappjs.com

101 pointsAndyBaker31 comments

So you need to install the application to make it work. Presumably, they install a HTTP API-driven binary on the system, and then they connect to it from your browser.

Not impressed.

This, on the other hand, is much more ambitious:

https://github.com/feross/webtorrent

Transmission had a http interface for a long time already. This seems like something quite similar. If you need to install a plugin or app to make it work it's not 100% "in the browser" imho.

https://trac.transmissionbt.com/wiki/WebInterface

Bizarrely, their first example app - http://www.paddleover.com - gives us this message:

   We currently only support OS X Lion. 
   Enter your email below and we'll let you know when 
   support is available.

Could there be a more user-hostile useragent detect script?

In any case; it's not a JS app, it's a plugin.

This requires the installation of some plugin to actually work. They made it sound like it was JS only.

Thanks, after reading the page I couldn't tell what this even was. Is it a library to do bittorrent in the browser, and if so what is Backbone a dependency for that? Using Backbone makes me think it's a UI, but there's nothing on the page to indicate that.

It looks like Backbone is used for the event model

That's confusing... it's Backbone's event model basically just an Event Emitter? Is there some special functionality that warrants bringing in all of Backbone vs. just using one of the millions Event Emitter libraries that are out there. You can even get just Backbone's models if that's what you want.

No. There isn't.

Source: I've ported most of the whole thing to pure angular.js. The code is riddled with UI elements directly being injected based on events, where it could have been a service API.

Kinda unfortunate that browsers don't allow general socket access.

The browser could ask for permission (and possibly disable access to cookies or saved credentials for this tab), and it would be pretty safe. You can do that with a signed Java applet, and I believe it was possible with Flash and a couple other techniques, but they have all been killed or are on the way out.

Imagine what you could do... Bittorrent clients, something like Popcorn Time, Anonymous P2P, Anonymous instant messaging, Tor in the browser, ... or less nefariously, Mail clients, Mashups, ... all in simple HTML files, hosted anonymously on a free webhoster. You can build awesome stuff, but can't be hold accountable by your domain name, etc..

puts tinfoil hat on The paranoid part of me thinks the restriction is on purpose, to prevent this kind of app in the browser. Apple, Google & co. control the walled gardens of their App stores. They don't control the "open" web, but they have subtly pushed it in a direction where it is very powerful, but has very specific weaknesses.

The restriction is on purpose to prevent browsers from becoming botnets.

That's the official excuse?

"official" there's nothing official about the web or web browsers. mozilla or google could release a socket implementation specific to their browser without waiting for the consent of w3c or rfc or else.

There's a risk for DDOS though, which have a high cost. But XSS is a risk too, so I don't see why js sockets would be so dangerous.

Any software installed in a computer can turn the machine into a zombie. Why don't we lock everything down, or better yet, block the computers access to the internet, after all, no net, no DDoS...

> Any software installed in a computer can turn the machine into a zombie.

That's not true about javascript.

Also the DDoS attack risk is low, it would happens only as people would visit infected websites or with XSS attacks. You can't have a botnet with js if the browser isn't turned on on an infected webpage.

So, all said, the restriction doesn't make much sense. I knew we would agree.

I agree that there is a very strong risk for DDOS, but I don't see how it would make botnets possible.

Allright, so I stumbled upon this as well last week, and i'm kinda disappointed with the whole thing. It's unstable at best (Mostly due to the RPC methods failing violently in JQuery), the 'we need torque' popup is annoying and built-in to the source and it requires Backbone, jQuery, underscore and multiple other dependencies before you can use it in your own project.

BtApp.js itself runs on Torque, Bittorent's attempt at a headless version of uTorrent, that provides some browser interactions over the btapp.js api.

The thing is: Torque is kind of a black box. I've installed it and then quickly got rid of it as soon as I noticed it ran an 80mb process in the background of which i couldn't tell if it was downloading torrents or not. A headless torrent client is nice, but not if you can't see what it's doing.

The cool thing about this though it is that the api can connect to uTorrent (v3.3+)/BitTorrent client and that that's completely working in production already (at least on windows systems)

Just last week I've reverse engineered the protocol and made an angular.js implementation of this that removes all the dependencies to backbone and cleans up the code, separating UI-elements from the actual communication service. I've dropped support for Torque though.

Thus, born was DuckieTorrent:

Github:

https://github.com/SchizoDuckie/DuckieTorrent

Live demo:

http://schizoduckie.github.io/DuckieTorrent/

You can authenticate it to your local uTorrent/Bittorrent account, it'll slurp in and process all information it receives and you can control your torrents, start streaming them via HTML5, even launch your uTorrent's configured player, wether thats the internal one or VLC, no problem.

A pluginless distributed P2P over WebRTC would be interesting!

The whole trust could be built client side and the servers used only for handshaking clients. We could then imagine clients that are aware of multiple servers and distribute both the client webApp & server on different URLs and the whole network could somehow connect in a yet to be defined network structure for efficient traversal.

The one part missing is a w3c standard allowing web of trust signing of the packaged webApp, debian keyring style, to be able to host it anywhere and still trust some set of developers.

Here's another app for torrents: http://jstorrent.com. It is a torrent client itself, no outside client needed, though proprietary.

WebRTC torrent (work in progress, not mine.) https://github.com/feross/webtorrent

They are terrible at explaining what it is.

Can I download torrents directly in the browser? Is it an UI to some underlying service? Can I seed with pure JS?

As far as I know you need a client running (torque, or µTorrent (+ a browser extension?)) and then you can interact with it using btapp.js

Last time I checked there was no torque support for Linux (yet).

I do agree, they are terrible at explaining what they have.

They also don't explain what Torque is.

Exactly this, I thought "torrents in the browser in a js app? Sounds good!" , but itlooks like its a clunky web interface (that you need to install) for a headless torrent client (that you need to install).

Its not a torrent client in the browser, its an overly complex interface API.

Why you wouldn't just use the transmission API is beyond me.

This came up a few months ago on HN under a different name. BTapps is a js torrent library that you can use to integrate into your apps or build something on top of it. But so far I have not been able to figure out how to use it.

>But so far I have not been able to figure out how to use it.

Have you looked at the tabs on the top of the screen? (Getting started, code snippets, etc.)? There is even a video of live coding with it.

Did the app get pulled? Right now it's just showing someone's personal homepage: http://i.imgur.com/J8x5TwY.png

Reply on news.ycombinator.com