I make torrents to publicly distribute some large datasets that would be prohibitively costly to serve from my blog, which uses an expensive CDN. My goals with these torrents are to serve content in a sustainable and performant way long-term.
To be clear, this is for legal torrenting, ex. the lawful distribution of large files - not piracy.
- Using your favorite flavor of Linux
- Install mktorrent
mktorrent -w "<your webseed (optional)>" \ -a udp://tracker.openbittorrent.com:6969/announce \ -a udp://exodus.desync.com:6969/announce \ -a udp://www.torrent.eu.org:451/announce \ -a udp://tracker.torrent.eu.org:451/announce \ -a udp://tracker.opentrackr.org:1337/announce \ -c "<descriptive comment>" \ <file or folder you're making into a torrent>
More trackers is not better (data, comments) and torrent clients using DHT, PeX, etc. while downloading publicly-available torrents really need 0-2 trackers. I prefer to add a handful of long-lived trackers (~5), so that even when some of them die, there will still be a couple of trackers online to help bootstrap new leeches with swarm information. I think this is an acceptable tradeoff between waste and longevity.
The trackers I currently use are below:
I generally avoid setting custom piece length using mktorrent (using the
-l flag) as the default piece size selection is often reasonable. There are more opinions on this (Vuze wiki, comments) but I will usually only fiddle with this if the default piece length selected by mktorrent results in an extraordinary number of pieces (ex. >10k).
Web Seeds (Optional)
I publish all torrents with a web seed (BEP-0019 / GetRight style web seeds) referencing my website
https://getright.tweedge.net/ - not everyone does, so I’ll explain.
Essentially, this is just a regular webserver with a copy of the files on it. Because data referenced by a torrent is static and unchanging, you can either get a low-cost/low-power webserver, or you can host the files in cheap object storage (ex. S3-compatible storage) and use a CDN to serve them - eliminating the cost and maintenance of servers altogether. I chose the latter, and my web seed is currently run with bunny.net (Volume CDN + storage) and limits download speeds per IP. This ensures that my torrents are always online, but for popular torrents such as rockyou2021.txt leechers will principally rely on the swarm, reducing the costs I bear personally.
The caveat here is that if only a web seed is online, and someone attempts to download your torrent with a magnet link, they won’t be able to because the torrent file itself cannot be discovered (as there are no peers online who can send a copy). I wrote torrent-fish to address this gap, which is a lightweight metadata-only peer which can resolve magnet links to torrent files (and leave the actual file-serving to the web seed). This is important for my torrents because there are some very niche torrents I have, such as 30GB of my cat’s DNA, which I don’t want to serve using an always-on seedbox as there aren’t enough downloaders to justify that expense.
- Using web seeds is cheaper than running your own torrent client 24/7
- Using web seeds scales better when you are distributing a lot of data (it’s what the Internet Archive does!)
- Setting up a web seed is more involved
- Setting up a web seed and either a seedbox or torrent-fish may be significant effort for niche usecases
Summary: Most people don’t use a web seed, and will just seed their torrent normally. To be clear, that is perfectly OK!