For some fun confusion, there's this libtorrent library, commonly called libtorrent-rasterbar by distros. And libTorrent by rakshasa, which is used by rTorrent.
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.
Question: why did noone extend the torrent protocol to understand http[s] and speak to servers that support resume?
edit: I’m just now reading https://www.bittorrent.org/beps/bep_0019.html and that’s exactly what they did. My bad
Kind of a tangent, but how large or small is the risk of nefarious sites running torrent nodes without the user's knowledge or consent?
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?
Im not up to date on webtorrent, but if it catches on does that mean a good chunk of the Inter net could be freed from cdns?
I expect enterprise IT will soon want a way to block this sort of thing, if it becomes popular. It risks killing WebRTC for serious applications...
I recently wrote a fun thing using libtorrent-rb: https://rwmj.wordpress.com/2020/06/25/nbdkit-with-bittorrent... It's a way to download, install and upload Linux distros all at the same time.
This is great news and will help lead to wider adoption. I hope that some progress will be made for handling large files since currently it is stored in-memory: https://github.com/webtorrent/webtorrent/issues/86
Once WebTorrent is ubiquitous among desktop and headless clients, the networks will become a lot stronger. Especially for applications like BitChute and for anyone who copies their approach. It solves a major problem with the cost of baseline hosting vs. hosting at scale.
When opening the javascript codepen demo linked in the article, the video plays immediately, but I noticed HTTP GET requests to https://webtorrent.io/torrents/Sintel/Sintel.mp4
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 ?
I'm torn on this one.
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. ¯\_(ツ)_/¯
The amount of word feross has put into P2P systems over WebRTC is astonishing.
Thanks feross for your incredibly great work!
Is there a good book that explains all the BT technology? I’d like to use or build a robust client/server but most learning materials seem to be trivial or daunting.
Are webtorrent connections encrypted? If they are not, then I'd rather they "break" legacy support now, when almost no one uses it (relatively speaking) than after a billion users and tens of thousands of enterprises use it.
A while back I built out a proof-of-concept distributed web based on webtorrents - https://github.com/tom-james-watson/wtp-ext. Once this change makes its way into popular clients, it makes the idea a whole lot more viable.
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.