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.
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.
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.
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.
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.
"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.
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.
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.
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).
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.
Not impressed.