Webtorrent – BitTorrent over WebRTC
github.com
github.com
It's very basic, and doesn't have proper error messaging. Would recommend only attempting to stream mp4 (h264) if you're giving it a shot.
Note: sorry for any grammar issues, on mobile now
Of course, it's not perfect. It appears to try and load the entire file to memory to seed, which makes sense, but that means you can't transfer a 1GB file without using 1GB of RAM...
The help me seed it is not working atm, but the idea is that you don't have to stay seeding it.
https://github.com/nicoSWD/put.io-adder/blob/master/README.m...
thanks, I'll try it out.
WebRTC should always be gated behind permissions. Most uses are video/audio, which already require a prompt, so no problem. Other websites shouldn't have this capability, so annoying users is no problem. But that's not very palatable, as it means acknowledging that WebRTC data doesn't really belong on the wider web.
Honestly, what are the real good uses for it outside of media? Games? WebTorrent?
I'm rather annoyed that such a feature was deployed, giving any webpage the ability to override my proxy settings or otherwise change the normal browser networking behaviour.
If WebRTC prompted or forced use of the HTTP connection settings in the browser, I'd have no issue with it.
media.peerconnection.ice.default_address_only
Security is a legitimate concern, but the browser is already completely exposed since it downloads and runs arbitrary code all day long.
I do have some objection to WebRTC but it's more architectural. WebRTC is overly complex, overly monolithic, and bloated. It tries to do too many things with one standard.
And even then you might want to consider building a new image each time with a random os / browser combo. Be sure to install some random toolbars and extensions and enable random configuration options too or else you might just end up leaving handprints instead.
Also, as per EFF's Panopticlick, fingerprinting isn't nearly a lost cause. And even then it's thrown off by changing UAs due to updating versions.
If you:
- upgrade your browser
- switch to a new IP
- wipe all your cookies
- change your browsing habits dramatically
(don't visit the same 10 websites over and over again)
Then maybe you could avoid re-acquisition.
IP address is a big one, but if browsers respected your explicit proxy settings instead of ignoring it for WebRTC, then changing it is easy. History, supercookies, and other stuff is taken care of by private mode, or, at worst, wiping out all browser info (private mode doesn't clear HSTS).
My point is that all is not lost, that supercookies are not a given. Thus saying WebRTC gets a free pass because things are already broken is simply wrong and a misleading argument to push data channels in where they don't belong.
https://chrome.google.com/webstore/detail/webrtc-network-lim...
It's published by the Chrome WebRTC (of which I am a member) for just that purpose: to let you control that behavior.
This doesn't mean we should make an existing problem worse.
A UDP API for sockets (with user approval required and some restricrions), then perhaps ICE or maybe that should be in JS. Then an audio/video sampling and compression API.
You could use it to implement p2p collaborative editing in a productivity app, which could actually give you privacy and security benefits that aren't available when a central server is involved.
So sure, your data might go direct, offering therorical security. Similar to how Stripe and Braintree don't improve security against a malicious server (just change the form/js and it's game over), but help against accidental problems. But this isn't truly providing the end user any guarantees. But it's good marketing. Like Cryptocat.
http://help.opera.com/Windows/12.10/en/sitepreferences.html
localstorage, separate widget localstorage, separate userjs storage, Web SQL - you could limit/disable/define everything with fine granularity(disabled, quota, popup if quota exceeded) globally and per domain.
opera:config#PersistentStorage
Can you imagine something as crazy as letting user decide which sites are allowed to run Javascript? use localstorage? leave permanent cookies? use plugins? or something as weird as defining custom useragent string per website? All possible in Old Opera, No other browser will let you do that now afaik.
Today? Today you get Firefox forcing Pocket, Google serving Voice control binary blob, and all around people coming up with things that cant be fine tuned at the user level like webRTC. We are slowly moving to a point (wtf webassembly) to a point we will lose any control over whats flowing down the wire from the server and runs on our computers.
Dont get me wrong, I still have it installed along with newest Opera, but they are my 'something doesnt work in 12.x' browsers.
https://addons.mozilla.org/en-US/seamonkey/addon/torrent-tor...
Google cache (appears broken): http://webcache.googleusercontent.com/search?q=cache:https:/...
Edit: It appears that the OP's link was changed. Original was https://webtorrent.io/
until every torrent client supports it is not as useful as it could potentially be
That said, the browser will not return to only acting as a display conduit with no interactivity despite what some people would like to see...
If you want a better platform than the browser for server-driven interactive applications not requiring you to install extra applications, then build one. To date, there hasn't been a better, more open option.
And in doing so, a critical vulnerability:
https://www.mozilla.org/en-US/security/advisories/mfsa2015-7...
It's of course fine to ask what a project is for or how it addresses a specific concern, criticize substantively, and so on, but there should always be a baseline of respect for someone who tried something and put it out there.
Good thing it's open source then.
They interact with each other because of BEPs. This client is a prototype and if it's successful you'll have a whole new source of peers.
And before PeX was a BEP, before Vuze had a Mainline DHT plugin, it didn't interact with some clients either. Hell, even DHT [1] had to go through the same BEP process. Do you expect all software to start out complete?
No. I would expect a new torrent client to start with tracker announces and then peer communication.
Do you have any insight into the BT dev community as to whether WebTorrent is likely to be picked up in other clients?
I have no special insight but I think this is a really cool idea. What I do know is if they don't put up a BEP then it won't go anywhere.
It smells a bit like embrace-extend-exterminate to me, even if it's not intentional, it currently is a natural consequence of "claim to do X in a browser" without access to the underlying primitives necessary to do X in a standards-compliant manner.
In my opinion browsers need to provide thinner abstractions over posix apis (with the appropriate sandboxing and opt-in where necessary).
Sure, so don't support it. If no one supports the protocol or the app, then it will die. That's an acceptable outcome to some. I'm not saying anyone has to support it, I don't even have any vested interest in it. It's just an interesting project and I've spent far too long today on HackerNews defending it when I could be working on my own projects.
To me, it looks more like "Adding Bittorrent into Firefox is pretty much impossible, where can we start instead?"
>In my opinion browsers need to provide thinner abstractions over posix apis (with the appropriate sandboxing and opt-in where necessary).
NaCl & Emscripten should get you some of the way there.
Maybe with better browser-native interaction? A house starts with its foundation.
And calling it a torrent client while knowing that it isn't interoperable still leaves a bitter taste with me.
> NaCl & Emscripten should get you some of the way there.
they don't provide sockets or filesystem access as I understand it.
OK, but that doesn't change the important point.
Your comments make it clear that you know quite a bit in this area. Instead of venting annoyance, why not teach readers some of what you know? If you did so without snark you could add a lot of value to a thread like this. People are obviously interested in the topic or they wouldn't have upvoted the story to #1.
> or they wouldn't have upvoted the story to #1
The cynic in me says that happened because this is "X in Y lines of javascript, in the browser!". The one thing that is guaranteed to catch the attention of people here is reinventing the wheel--poorly.
However I think you would have more success in A) gaining an understanding of what someone is trying to achieve / what problem they might be trying to solve and B) sharing your likely very valid point of view / experience with others if you change the way you communicate your reply.
The way you worded your reply could be hurtful to the person that came up with the idea and spent their time to try and create something from it.
I'm sure your intentions are good, probably a mix of wanting to educate people, share your experiences and show heartfelt frustration with certain types of software trends or implementations.
I think it would be more constructive and less potentially hurtful if you focused on talking about how you could see issues with using X to do Y and perhaps offer a suggested alternative path to look at if they're interested.
Tldr; If someone is demoing their ideas or product - friendly constructive criticism and feedback is very important and valuable. Keep comments positive and your words will have more of an impact.
As for software trends: all hope is lost.
Sad but true. The rate at which software quality is decreasing is increasing all the time. e.g. even though I haven't upgraded my phone's OS for over a year (I have tried, but the newer versions are always broken in some important way!), Google pushes out updates to Play Services that I can't block that cause crashes, dead batteries, broken apps and features, etc.
This is why, more and more, I gravitate toward not only FOSS software, but stuff like Emacs that Just Keeps Working. It seems like hardly any software developers care anymore about making things that actually work. Imagine if modern cars broke as often as most computer software does. (And as cars come to depend more on complex software, they are going to get less reliable--just as they were getting to be very reliable.)
While JavaScript is probably slower and use much more resources, it's not always the case.
I would also argue that bit-torrent doesn't take up much resources, at least when only seeding a few files, I guess you would have to seed thousands of files for performance to matter.
The IRC-like chat on Social Savannah will run up your browser memory and until you run out and crash. pdf.js (in firefox), as mentioned, starts sucking down cycles and bytes with just intel reference manuals open.
Rather than restricting what browsers can send and making kludgy workarounds that waste resources, why don't we just allow browsers to send whatever they want?
But when I asked for a concrete example that doesn't involve audio or video, I literally got "suppose you are using the web UI on a refrigerator, you might want a data channel to go direct to the fridge instead of to the webserver". At least BitTorrent is a more reasonable example.
Furthermore, data channels break the security model of a browser just using HTTP as configured, as WebRTC bypasses your proxy settings without notice.
WebRTC data channels should NOT be enabled by default and should cause a dialog, as shitty as that is. My approach is to disable it and stick my head in the sand and hope it'll go away, but people seem irrationally excited about it. Basically WebRTC right now is shittier than NetMeeting (1996) but "cool".
Now if someone could explain why I'm getting downvoted to hell...
10 points gone so far. I've never experienced this. Are people really that uncomfortable with opinions? Perhaps I've slain someone's sacred cow :)
Plus permissions dialogs sorta don't work, especially for something like networking. "This page wants to use the Internet: Allow?" would just confuse the hell out of users. The alternative, acknowledge that WebRTC data should be a really limited use case, doesn't appeal to the authors/implementors.
Yes: javascript and browsers. But its just imaginary internet points, they don't really matter that much.
Off the top of my head I can't think why WebRTC wouldn't work with normal SOCKS proxies though, like NNTP and mail protocols did.