Obvious to many I'm sure, but maybe best to be explicit about it anyways.
Slightly off-topic but kind of fitting: How does infohash v2 support look like today? It's been available for years, but seemingly most private trackers + most other places seems to still be using v1. What clients are people using today, do those support v2? As far as I know, all modern clients do, so it would be possible to start using v2 exclusively.
Reason for the question is that I'm planning to distribute many large files to the public, and in my experience, BitTorrent works really well for that. Question is if it's enough to just publish v2 infohashes, or I need to publish both v1 and v2.
Obviously after a non-compliant party to the transfer has fully downloaded the file(s) it can do whatever it wants with it afterwards… flip any flags and share via DHT, etc.
I recently shared some —more or less— private data to someone else via BitTorrent. We just used DHT for convenience. It took like 15 minutes for other random peers to pop into the transfer. All of those random peers just fetched the meta data. And indeed, a check on btdig confirmed the whole metadata (file names, file sizes, etc.) leaked. So there's a lot of DHT network scanning going on for sure. It was rather fascinating. No actual data was downloaded/leaked at least.
There is an entire category of free software whose purpose is to create an index of the DHT network. :) The idea is to allow users to find and search for torrents in a completely decentralised manner (i.e. without relying on any centralised trackers or search engines).[1] A good example is bitmagnet[0].
[1] With the added benefit of greater resilience, as centralised "chokepoints" are often the primary and only targets of takedowns.
How else would btdig (and others) fill their index?
The standard solution is to compress what you're sending with 7zip, with a password.
> No actual data was downloaded/leaked at least.
I've had randos download the data before the intended recipient figured out how to open a port.
The short answer is: You just publish as v1 infohash as if nothing is different, but the info contains extra stuff for v2 supporting clients. v1 clients will still work, it's backwards compatible.
So generate your torrent files as hybrid v1/v2, then just do everything else like you always have. Pretend v2 isn't a thing.
v2 clients know how to tap into both swarms and will take advantage of improvements when applicable. It's very well designed.
So if I do v1, why do v2? If I do v2, I'd like to skip v1. Ideally I'd do v2 (only) as it seems a heck more future-safe with sha256.
Edit: Actually, I think I see what you're saying. Create hybrid torrent that works with both, share the v1 infohash of that one, v2 clients will automatically take advantage of v2 from that if supported, sounds right?
tar | gpg --symmetric | torrent
That will help me to stop relying on known and popular public trackers[1] in order to share files.
Others might find the link useful, though!
It's automatically pushed to docker hub.
docker run -it --rm meehow/privtrackerI sometimes wonder how LLMs will impact this. They're much better at surfacing this kind of arcane knowledge than traditional search engines, and that risks increasing accessibility.
If accessibility gets too high, the ISPs could respond against it.
E.g, in Brazil, Greece and (if you know where to look) even here in Berlin, it is not that difficult to find set top boxes that come with Kodi pre configured with a private tracker and some custom frontend to download movies and shows on demand. In Brazil you buy the box and you pay something like R$200 ($35) per year.