Hacker News new | ask | show | jobs
by asdfaoeu 4573 days ago
I've actually been thinking about this a bit as well.

I think you can just avoid the torrent file completely and use a merkle tree hash like how new torrent files work and then you end up with just one torrent file per file. And have peer acquisition work through DHT

Directories would be simple and just a matter of creating a new "file" with hashes and names of the contents like how git directories (extending on this you can have a version control system like git).

A noticeable change is that each individual file is uniquely shared. This I believe is both a feature (avoiding duplicate torrents for the same file) as well as means that anyone can see whos downloading a file a solution would be another key hash which causes the dht id to be hashed again to allow individual darknets.

1 comments

I agree that advertising single file Merkle tree roots on the DHT is a good thing, and that one could nicely build git-like directory structures, but why force the leaves of the tree to be singleton torrent files?

Why not instead advertise individual files on the DHT by their Merkle tree roots, and put the Merkle tree roots in each entry of the "files" section of the torrent file? This doesn't force re-packaging of existing torrents into singleton torrents. Seeders can advertise single files from old torrents and clients with new torrents can take advantage of this advertising.

I disagree with the munged-key darknet idea. If you want a darknet, run it on a non-public DHT, with cryptographic handshakes and encrypted traffic. Cryptographically munging the DHT keys on a public DHT only creates a "light grey net" that's trivially circumvented and provides a false sense of privacy.

> Why not instead advertise individual files on the DHT by their Merkle tree roots, and put the Merkle tree roots in each entry of the "files" section of the torrent file?

You can't do that because torrents aren't file delimited, they are block delimited. You can't check 2 files are the same across torrents without first downloading both torrents.

You misunderstand. This has nothing to do with comparing two torrents. Comparing two torrents solves the wrong problem.

Clients that have downloaded all of the data for a single file (but may or may not have downloaded all of the data for the full torrent) have the data for the file and can calculate the Merkle tree root for that file, and advertise availability on the DHT.

Clients with new style torrent files that included Merkle tree roots in file descriptions would then be able to download those files. This has nothing to do with comparing torrent files.