It's so fulfilling to see WebTorrent still popping up on Hacker News after all these years. I started the project in 2013 and devoted most of my 20s to working on it, ultimately becoming a full-time open source maintainer. I started WebTorrent with the goal of extending the BitTorrent protocol to become more web-friendly, allowing any browser to become a peer in the torrent network. Within less than a year of starting the project, I got WebTorrent fully working (see https://news.ycombinator.com/item?id=8317441). And it worked _well_, beating many native torrent apps in terms of raw download speed and the ability to stream videos within seconds of adding a torrent.
WebTorrent never got as much attention as the cryptocurrency projects selling tokens throughout the mid-2010s, even though WebTorrent _actually worked_, and it had more users than almost all of them :) I was never tempted to add a cryptotoken to WebTorrent, despite many well-meaning friends telling me to do it and cash in. Nonetheless, WebTorrent served as an accessible on-ramp to the world of decentralized tech, along with other projects like Dat (https://dat-ecosystem.org/) and Secure Scuttlebutt (https://scuttlebutt.nz/), playing a role in getting people excited about decentralization.
But WebTorrent is more than a protocol extension to BitTorrent. We also built a popular desktop torrent client, WebTorrent Desktop (https://webtorrent.io/desktop/), which supports powerful features like instant video streaming.
We also built a `webtorrent` JavaScript package (https://socket.dev/npm/package/webtorrent) which implements the full BitTorrent/WebTorrent protocol in JavaScript. This implementation uses TCP, UDP, and/or WebRTC for peer-to-peer transport in any environment – whether Node.js (TCP/UDP), Electron (TCP/UDP/WebRTC), or the web browser (WebRTC). In the browser, the `webtorrent` package uses WebRTC which doesn’t require a browser plugin, extension, or any kind of installation to work. If you’re building a website and want to fetch files from a torrent, you can use `webtorrent` to do that directly client-side, in a decentralized manner. The WebTorrent Workshop (https://webtorrent.github.io/workshop/) is helpful for getting started and teaches you how to download and stream a torrent into an HTML page in just 10 lines of code.
Now that WebTorrent is fully supported in nearly all the most popular torrent clients, including uTorrent, dare I say that we succeeded?
It's been a long and winding journey, but I'm glad to have played a role in making WebTorrent happen. Huge shoutouts to all the open source contributors to WebTorrent over the years, but especially Diego R Baquero and Alex Morais who were critical to WebTorrent's success.
If you're curious what I'm up to now... I'm building Socket (https://socket.dev) with an awesome team of open source folks. And there's actually a WebTorrent connection, too! Before Socket, we built an end-to-end encrypted file transfer app, Wormhole (https://wormhole.app), using WebTorrent under-the-hood (Show HN thread: https://news.ycombinator.com/item?id=26666142). Like Firefox Send before it, security was a primary goal of Wormhole (see security details here: https://wormhole.app/security). But one area where we felt we could improve the security of Wormhole was in how we audited our open source dependencies.
Like most teams building apps with JavaScript, we had a large `node_modules` folder filled with lots of constantly-updating third-party code. The risk of a software supply chain attack was huge, especially with 30% of Wormhole visitors coming from China. As most teams do, we enforced code review for our first-party code; but as most teams do, we pulled in third-party dependencies and dependency updates from npm without even glancing at the code. It's too much work to read every line of code of all dependencies. But the status quo would leave our users open to supply chain attack and we wanted to do better for our users. We looked around for a solution to detect signs of attack and to analyze the risk of various open source packages, but none existed.
So we built Socket to help developers ship faster and spend less time on security busywork by helping them safely find, audit, and manage OSS. By analyzing the full picture – from maintainers and how they behave, to open-source codebases and how they evolve – we help developers and security teams to identify risk from malware, hidden code, typo-squatting, misleading packages, and more.
Very nice overview - thanks for this. Q: what's your take on the path to a possible a web browser based DHT that could be used instead of tracker servers (or anything, really.) I've seen a variety of people trying to figure this out but I don't think any solutions have popped out.
I was looking into (ab)using webtorrent trackers as webrtc signalling servers but instead decided to write a cloudflare worker to do it [1], which is kind of a half-step towards a 'serverless' signalling layer. The next step would be to get a decentralized network that allows you to run cloudflare workers off of cloudflare. But a true DHT would be ideal.
As someone who's built (and is still currently working on) an app that integrates WebTorrent, I want to thank you for resisting the temptation to cash in on the token craze while so many other decentralization-adjacent projects have been ruined the get-rich-quick crowd. It gives me hope that some of that original ethos is still alive. And good luck with Socket. Super important work.
It's so fulfilling to see WebTorrent still popping up on Hacker News after all these years. I started the project in 2013 and devoted most of my 20s to working on it, ultimately becoming a full-time open source maintainer. I started WebTorrent with the goal of extending the BitTorrent protocol to become more web-friendly, allowing any browser to become a peer in the torrent network. Within less than a year of starting the project, I got WebTorrent fully working (see https://news.ycombinator.com/item?id=8317441). And it worked _well_, beating many native torrent apps in terms of raw download speed and the ability to stream videos within seconds of adding a torrent.
WebTorrent never got as much attention as the cryptocurrency projects selling tokens throughout the mid-2010s, even though WebTorrent _actually worked_, and it had more users than almost all of them :) I was never tempted to add a cryptotoken to WebTorrent, despite many well-meaning friends telling me to do it and cash in. Nonetheless, WebTorrent served as an accessible on-ramp to the world of decentralized tech, along with other projects like Dat (https://dat-ecosystem.org/) and Secure Scuttlebutt (https://scuttlebutt.nz/), playing a role in getting people excited about decentralization.
But WebTorrent is more than a protocol extension to BitTorrent. We also built a popular desktop torrent client, WebTorrent Desktop (https://webtorrent.io/desktop/), which supports powerful features like instant video streaming.
We also built a `webtorrent` JavaScript package (https://socket.dev/npm/package/webtorrent) which implements the full BitTorrent/WebTorrent protocol in JavaScript. This implementation uses TCP, UDP, and/or WebRTC for peer-to-peer transport in any environment – whether Node.js (TCP/UDP), Electron (TCP/UDP/WebRTC), or the web browser (WebRTC). In the browser, the `webtorrent` package uses WebRTC which doesn’t require a browser plugin, extension, or any kind of installation to work. If you’re building a website and want to fetch files from a torrent, you can use `webtorrent` to do that directly client-side, in a decentralized manner. The WebTorrent Workshop (https://webtorrent.github.io/workshop/) is helpful for getting started and teaches you how to download and stream a torrent into an HTML page in just 10 lines of code.
Now that WebTorrent is fully supported in nearly all the most popular torrent clients, including uTorrent, dare I say that we succeeded?
Not only that, but we helped the JavaScript ecosystem a ton by writing hundreds of npm packages including buffer (https://github.com/feross/buffer), simple-peer (https://github.com/feross/simple-peer), and StandardJS (https://standardjs.com/).
It's been a long and winding journey, but I'm glad to have played a role in making WebTorrent happen. Huge shoutouts to all the open source contributors to WebTorrent over the years, but especially Diego R Baquero and Alex Morais who were critical to WebTorrent's success.
If you're curious what I'm up to now... I'm building Socket (https://socket.dev) with an awesome team of open source folks. And there's actually a WebTorrent connection, too! Before Socket, we built an end-to-end encrypted file transfer app, Wormhole (https://wormhole.app), using WebTorrent under-the-hood (Show HN thread: https://news.ycombinator.com/item?id=26666142). Like Firefox Send before it, security was a primary goal of Wormhole (see security details here: https://wormhole.app/security). But one area where we felt we could improve the security of Wormhole was in how we audited our open source dependencies.
Like most teams building apps with JavaScript, we had a large `node_modules` folder filled with lots of constantly-updating third-party code. The risk of a software supply chain attack was huge, especially with 30% of Wormhole visitors coming from China. As most teams do, we enforced code review for our first-party code; but as most teams do, we pulled in third-party dependencies and dependency updates from npm without even glancing at the code. It's too much work to read every line of code of all dependencies. But the status quo would leave our users open to supply chain attack and we wanted to do better for our users. We looked around for a solution to detect signs of attack and to analyze the risk of various open source packages, but none existed.
So we built Socket to help developers ship faster and spend less time on security busywork by helping them safely find, audit, and manage OSS. By analyzing the full picture – from maintainers and how they behave, to open-source codebases and how they evolve – we help developers and security teams to identify risk from malware, hidden code, typo-squatting, misleading packages, and more.