←back to thread

Resurrecting a dead torrent tracker and finding 3M peers

(kianbradley.com)
655 points k-ian | 1 comments | 17 Jun 25 17:40 UTC | HN request time: 0.22s | source
Show context
jauntywundrkind ◴[17 Jun 25 19:13 UTC] No.44302762[source]▶
I actually ran a very-short-lived private use tracker briefly, for some exploration doing p2p watch partying. But it was a toy, never got serious enough to look deeper at how the tracker worked (was using the rust Aquatic tracker, which kindly added webtorrent support on request! https://github.com/greatest-ape/aquatic )

Does the tracker know what it's tracking? Is there any attempt to make the tracker unaware of what peer rendezvous it's doing?

My gut is that it seems some kind of hash/magnet that folks are asking to peers on. And that the magnet itself is sufficient, and doesn't have to include anything identifying (although I believe many magnet links included some human readable description). The tracker could likely try to download this hash from the peer itself, to get the torrent info, but wouldn't really know what the torrent is or what's in it without doing the download itself.

Does that check out? How much of the magnet link is key to rendezvous? Could a tracker ignore human friendly fields, block them at ingress, to shield it's eyes?

replies(2): >>44304630 #>>44304816 #
1. daneel_w ◴[17 Jun 25 22:46 UTC] No.44304816[source]▶
The trackers only deal with torrents' info hash. No names, no descriptions, no list of contents, no nothing. opentracker, to use OP's chosen software as example, can run in both white- and blacklist mode (or whatever equivalent terminology it uses today). The former is self-explanatory, and the latter allows all hashes except the blacklisted ones. All open trackers, such as torrent.eu and opentrackr.org to name a couple, always operate in a blacklist fashion in order to openly accommodate any users to congregate for (almost) any content.