Press play the moment a torrent starts. Torrent Live streams video and audio straight out of the swarm — skip ahead and it fetches the pieces that part of the file needs, so nothing waits for the download to finish. That's WebTorrent underneath, the streaming BitTorrent engine, running as a proper desktop app with the full peer swarm rather than a browser tab. The interface borrows from studio software: a session grid where every torrent is a clip with its own colour and its own level meter.
And it doesn't have to stay on this machine. Turn on sharing and the app becomes a
video server for the house — open its address on a phone or a TV and watch from there,
subtitles and all, even when the file is a .mkv no browser can open.
Streaming while downloading
127.0.0.1 · HTTP byte ranges
The interface, redrawn here in the browser. Meters advance on the app's own 500 ms snapshot tick.
Pieces arrive from many peers at once and in no particular order. Your machine puts them back together, and because it knows which part you are watching it asks for that part next — which is why playback starts before the download finishes. Anything a browser cannot open is repackaged as it plays. What leaves your machine goes only to your own wi-fi.
Rosetta gets pulled into an Electron app one of two ways: the Electron binary
itself is x64, or a dependency loads a compiled .node addon built
for x86_64. This build closes both doors.
Electron is arm64. Electron 43 ships native Apple Silicon builds,
and the packager targets arch: [arm64] explicitly. The running app
reports its own architecture in the top-right badge — green for
arm64 native, red the moment it is ever translated.
Nothing is ever compiled. WebTorrent pulls in five optional native
accelerators. Every one has a pure-JavaScript fallback, and every one ships a
prebuilt darwin-arm64 binary. Packaging sets
npmRebuild: false, so node-gyp is never invoked: no compiler, no
Xcode toolchain, no chance of an x86_64 object being linked into an arm64 app.
Flip Share on LAN and the app starts serving on your network. Open its address on a phone, a tablet, a smart TV, or another laptop and you get a full browser interface — every torrent, every file, progress bars that keep moving, and click-to-play. Still downloading? It still plays, and seeking still works.
No browser can open a Matroska file — there is no engine on earth that ships a
demuxer for it. So the app repackages it as it streams: ffmpeg rewraps the same
video into a format the browser accepts, usually copying the picture through
untouched rather than re-encoding it. Safari and TVs get HLS, Chrome gets
fragmented MP4. You just press play.
The same goes for an .mp4 holding H.265 — the container opens but the codec does not, so that is repackaged too, and only for the browsers that need it.
Subtitles buried inside the video file are pulled out and offered as tracks. Ones sitting beside it are converted and offered too. And if the release shipped without any, the finder identifies the film by a hash of its actual bytes — the same trick VLC uses — so what comes back is timed against your exact copy instead of drifting out of sync.
WebTorrent runs in Electron's main process, not the renderer. That's deliberate: the main process can open raw TCP sockets and speak DHT, so the app reaches the ordinary BitTorrent swarm. A renderer-hosted client would only ever see WebRTC peers.
The sandboxed renderer can't read a torrent's chunk store, so the main process serves each file over 127.0.0.1 with HTTP byte-range support. Selecting a range tells WebTorrent to prioritise those pieces — video plays before the download finishes, and seeking pulls the pieces it needs.
Context isolation on, node integration off, sandbox on, and a restrictive CSP where
media-src allows only 127.0.0.1. The stream server validates every
infohash against a 40-hex pattern before touching a file, and external links open in
your browser, never in-app. Sharing to the network is off until you switch it on —
until then the server isn't reachable from anywhere but this machine. Switch it on
and it is open to your LAN, which the app says plainly at the time.
Torrent Live 0.2.4
Signed with a Developer ID certificate, notarized by Apple, and the ticket stapled to the app. Open the disk image, drag it to Applications, and it launches — no warning, no right-click, nothing to paste into a terminal.
Check it yourself if you like — it should answer accepted:
spctl -a -vvv "/Applications/Torrent Live.app"
There's no x64 build. The point of the project is an app that never touches Rosetta,
so it ships arm64 only. On an Intel Mac, build from source with
npm run dist:universal.
Torrent Live 0.2.4
The installer isn't code-signed, so SmartScreen will show "Windows protected your PC". Choose More info, then Run anyway. It installs per-user by default, so it never asks for an administrator password, and you can change the install location on the way through.
The optional native accelerators are built for macOS, so the Windows build falls back to the pure-JavaScript paths they were always designed to fall back to. In practice that means TCP rather than µTP transport. Everything else behaves the same.
Torrent Live 0.2.4
An AppImage is a single self-contained file — nothing to install. Mark it executable and run it:
chmod +x Torrent-Live-0.2.4-x86_64.AppImage && ./Torrent-Live-0.2.4-x86_64.AppImage
On some distributions you may also need libfuse2, which AppImages
use to mount themselves.
There's a .deb as well
(—), if you would rather it went through your
package manager:
sudo apt install ./Torrent-Live-0.2.4-amd64.deb
Download the .deb — SHA-256 —
Every one of those is up for grabs. The source is on GitHub, and the README walks through the architecture — why the torrent client lives in the main process, how the loopback stream server works — before you touch anything. Issues and pull requests are welcome.
View the sourceTorrent Live is, honestly, a front end. Everything that makes it a torrent client — the DHT, the peer wire protocol, piece selection, the streaming that lets a video play before it has finished arriving — is WebTorrent, written by Feross Aboukhadijeh and WebTorrent, LLC. This project contributes an interface and a macOS shell around it.
If you find this useful, the upstream project is the thing worth starring, funding and contributing to: webtorrent.io · github.com/webtorrent/webtorrent.
This project's own source is at github.com/juananime/torrentlive, MIT licensed like everything it stands on. Contributions welcome.
Every component below is MIT licensed, and each one's full licence text ships inside the application bundle as required.
| Component | Version | Copyright |
|---|---|---|
| WebTorrent | 3.0.21 | © Feross Aboukhadijeh and WebTorrent, LLC |
| Electron | 43.4.0 | © Electron contributors; © 2013–2020 GitHub Inc. |
| React | 19.2.8 | © Meta Platforms, Inc. and affiliates |