Unfortunately it looks like Mozilla's interest in the distributed web died when they made redundant the main stakeholders in the project last year - https://github.com/mozilla/libdweb/issues/109.
I personally work on a decentralized web project ... but even I can't fault them for shutting down side projects. Every project either needs to provide alternative revenue streams or feed into getting Firefox on par with Chrome's speed, security, and feature set. Hopefully Chrome will follow through with neutering their ad-blocking and people will switch back to Firefox.
It doesn't really matter anyway since you have access anything firefox can do with webextensions experiments, which was required since libdeweb isn't a part of firefox(and won't be anytime soon because AFAIK most people who were working it has been laid off) and to run experiments you need firefox nightly.
Here's the bug I had referred to the libdweb person at the time in November of 2018 (due to comment #2):
> RTCPeerConnection.createOffer doesn nothing in WebExtension background script
This bug had already been resolved in September of 2018 as a duplicate of this bug:
> WebExtension cannot access WebRTC mic from popup.js nor background.js
And I now see that bug ended up getting resolved in September of 2019 as a duplicate of this bug:
> Improve getUserMedia permission model for web extensions a bit.
Which was supposedly fixed? I'm honestly a bit concerned still, though, as this bug slowly got dragged from being about createOffer to being about permissions dialogs for audio/video, and it kind of sounds like there's some weird thing where a "foreground page" has to vouch for the extension, which shouldn't be required. Everyone who works on WebRTC stuff in browsers conflates it all with getUserMedia, but all of us distributed web people just want peer-to-peer data channels :/. I take it this is actually fixed then, and you can now use WebRTC in this context?
I've considered something like this for a web music player I have, but it doesn't seem to have an easy setup for downloading individual files from a torrent. And the latency would add gaps between songs.
Schedule your fetches intelligently and it shouldn't be hard to keep a music player fed. 320kbps is only 40KB/s.
You can't preload the next song ahead of time?
You might want to mess around with the piece picker, there's options specifically for streaming. http://libtorrent.org/reference-Core.html#set_piece_deadline
edit: I’m just now reading https://www.bittorrent.org/beps/bep_0019.html and that’s exactly what they did. My bad
so you can't just curated a data collection from publicly accessible sources and freely map torrent contents to files on http for bootstrapping/reliability.
too bad, really. it seems like a cool thing to just make a torrent from e.g. public datasets that are hosted on flimsy university servers. make the torrent, distribute it, the swarm keeps the files available and reduces load on the university servers, and the server keeps the torrent from dying even if the dataset is niche.
We've seen something similar with using JS to mine bitcoin. That gets you money, so that probably has a stronger incentive, but someone might want to gain access to the resources this would allow.
The WebTorrent FAQ (https://webtorrent.io/faq) says this uses WebRTC and further says:
> WebTorrent clients running on one domain can connect to clients on any other domain. No silos! The same-origin policy does not apply to WebRTC connections since they are not client-to-server.
Does the browser do anything to protect the user against something like this? Is there a permission for network access, and is it allowed or denied by default?
WebRTC data channels are allowed by default.
> Does the browser do anything to protect the user against something like this?
A nefarious website can already use the fetch() API to upload or download massive amounts of data if their goal is waste bandwidth. WebRTC doesn't introduce any new vulnerability here.
It could however lower costs for people who distribute large files, where the final user can tolerate some download latency. I'm thinking browser games that can download a big archive via torrent on first launch, similarly to what Steam does now in their client.
Which mess did it cause?
Enterprise-IT people tend to shutdown first and ask questions later, to cover their ass (and in their shoes I'd probably do the same). If it becomes trivial to torrent via mainstream browsers, I expect they will lock down whichever feature is responsible or apply massive pressure on vendors to remove the feature.
You can't really forbid SSH (on paper only you can) since you can create SSH tunnels via virtually any port.
Worst case we could disallow WebRTC via DPI and whitelist it for category conferencing.
I think that's less likely to happen with WebRTC. But for workplaces that don't otherwise use it? Maybe.
Whereas IMs are an accepted part of business processes (i.e. "serious").
There was a very long period when IMs were not acceptable and actively blocked, especially at financial institutions that have a legal obligation to log and retain all internal communication for X years. I saw this at many different firms for many years.
That changed. perhaps torrent will, too. Nah, probably not :)
WebRTC isn't going anywhere. If you have a sales department, you can't block it.
I've personally been working around this using a custom fork that messes around with the simultaneous connections settings, and it seems to help quite a bit, but I still get freezing from time to time when I download a large number of torrents simultaneously.
I wonder if an alternative implementation in something like Rust on top of WASM might make those kinds of issues easier to avoid by making more efficient use of resources.
Torrents can be a great, standardized way of delivering updates for example, and network administrators can easily deploy a platform-agnostic way to deliver & cache updates on their network by just deploying a torrent client somewhere and their fleet would automatically discover them (using local peer discovery) instead of having to deploy multiple proprietary, platform-specific solutions.
I think they're just assuming that you don't want everyone to know exactly what you're doing online at all times by exposing your IP to everyone and their brother that uploads a resource.
Is this normal ? I know nothing about WebTorrent, but isn't the file supposed to be streamed from pairs, and not requested from a central server in an HTTP request ?
On the one hand it means the web moves (or can move) closer to decentralized modes of operation. Bittorrent is tried and tested and Works (TM).
On the other hand, it also means yet one more thing that moves into the freaking browser. We have enough things nowadays that are shoehorned into HTML/JS when really they would have been more usable even if written in tcl/tk.
You win some, you lose some I guess. ¯\_(ツ)_/¯
Transmission crashes for me, and has little activity. Sometimes it just can't open torrent files.
The web doesn't break. You can load a URL, get some decent software with an easily-improvable UI—and assuming you're on a modern browser—expect it to work with no installation, in seconds. And if a site pushes an update, I hit refresh and get the update without needing to run a 45-minute `pip install` command.
Oh, also, coming out of an hour long intercom session trying to explain to a customer rep how "no, I didn't change anything in my firefox, your site just suddenly doesn't log me in any longer" I'll posit that the web breaks all the time and all over the place, in many small, annoying ways.
Seriously though, you'll be hard-pressed to find a platform where you can't run at least rtorrent or such. and if you're running some esoteric unix from way back when, I expect you to be able to compile it for that yourself. :P
Thanks feross for your incredibly great work!
I also recommend just reading the BitTorrent spec. It's quite short and manageable as far as specs go.
After that, just read the BEPs directly: http://bittorrent.org/beps/bep_0000.html. They're small, easy to understand and straight to the point.
Then read the code for Webtorrent or other implementation in a language you're familiar with. You'll immediately recognize the BEPs there.