What if... BitTorrent clients partially ignored the private bit of a torrent? (lemmy.dbzer0.com)

submitted 1 month ago by ovovo@lemmy.dbzer0.com to c/piracy@lemmy.dbzer0.com

20 comments fedilink hide all child comments

Private torrent trackers have all the reasons to remain private, and I don't blame them for that and I am glad private trackers exists. But the torrent files themselves have a setting that says "this torrent is private", which makes the BitTorrent client to not distribute them via DHT, which makes magnetic links not work with them, so they are restricted to people who can obtain the torrent file from the private tracker.

What if clients had an option (on by default) to distribute the torrent via DHT and perform PEX, while still taking care to: a) not place the private tracker in the magnetic link the user might generate, and b) separate the upload/download statistics for the peers returned by the private tracker, so the ratio statistics in the private tracker are not skewed?

This way, private torrents could "escape" into the wild, still maintaining the privacy and social/closed community effects of the private tracker. Someone could download something for a friend or for a random person who asks for some content in a forum, send them the magnetic link, and don't have the private tracker activities or anonymity affected in any way.

What do you think of this idea? How do you think it would be received by private trackers and BitTorrent client developers? What are the drawbacks you can think of?

you are viewing a single comment's thread
view the rest of the comments

[-] brickfrog@lemmy.dbzer0.com 35 points 1 month ago* (last edited 1 month ago)

This way, private torrents could “escape” into the wild, still maintaining the privacy and social/closed community effects of the private tracker.

Except that it wouldn't. The infohash that the private flagged torrent generated is different vs a public non-private torrent of the same contents. Your suggestion would purposely share the same exact private torrent infohash into public DHT/PEX, that would certainly get people banned at the source private tracker(s). I also suspect most/all torrent client developers would consider that incorrect behavior.

If you wanted to do a more "correct" approach on this - Create a brand new public non-private flagged torrent of those contents, which would generate its own unique infohash, then it's just a regular torrent. You'd end up needing to seed multiple copies of the same torrent (the original private flagged torrent and your new public torrent) but sure that would be possible as long as the torrent client itself has DHT/PEX enabled. Most private trackers won't care too much but some of that does depend on individual trackers and uploaders, you'd need to check their rules.

[-] ovovo@lemmy.dbzer0.com 3 points 1 month ago

Your suggestion would purposely share the same exact private torrent infohash into public DHT/PEX,

Yes, but not necessarily. It is trivial to recompute the infohash with the private bit disabled. This would split the network, but that is probably a good thing to preserve the anonymity of the private tracker users, as pointed out by another commenter.

[-] ovovo@lemmy.dbzer0.com 4 points 1 month ago

Yes, with this solution, internally it could be seen a two separate torrents, but if it is an option easily accessible in the client settings, and it is handled transparently as a single torrent, much more people will do it, and the scene as whole would gain with the network effect.

[-] droolio@feddit.uk 4 points 1 month ago

More people should use BiglyBT and its Swarm Merging feature. You get the ability to seed or download chunks from peers across separate torrent files.

It's a shame because if more people used it, the BiglyBT devs might add hash-based merging (with v2 torrents) instead of just size-based. Hybrid/v2 merging is still possible, but file size is less reliable and caters to files only larger than 50MB.

Some kinda auto v1/v2/hybrid private<->public torrent maker plugin for BiglyBT would be... bigly.