Add column in content tab for torrent showing torrent file hashes

[memoryhash]

Suggestion

I would like to see end result file hashes of each file I am downloading. I guess there would be 2 columns, one showing hash type and the other showing the hash, since this would need to account for SHA-1 and SHA-256 between Bittorrent v1 and v2.

Use case

Know what on earth I'm downloading ahead of time.

Extra info/examples/attachments

something like this highly detailed mspaint mockup

[glassez]

I would like to see end result file hashes of each file I am downloading. I guess there would be 2 columns, one showing hash type and the other showing the hash, since this would need to account for SHA-1 and SHA-256 between Bittorrent v1 and v2.

BitTorrent has nothing to do with file hashes. You can calculate the hash only after downloading the entire file. Am I wrong?

[HanabishiRecca]

BitTorrent has nothing to do with file hashes. You can calculate the hash only after downloading the entire file. Am I wrong?

BitTorrent v2 does store hashes of individual files. For v1, yeah, it's impossible to know the checksum of a file before you download it.

[glassez]

BitTorrent v2 does store hashes of individual files.

If you mean "pieces root" hashes then yes.

[HanabishiRecca]

If you mean "pieces root" hashes then yes.

Yes. Although, it's not clear for me from the spec, if it corresponds to actual file content, or just stores "hash of hashes". If it's the latter, the OP's idea is impossible completely.

[glassez]

Although, it's not clear for me from the spec, if it corresponds to actual file content, or just stores "hash of hashes".

In short, yes - a "hash of hashes".

If it's the latter, the OP's idea is impossible completely.

We can display such "pieces root" hashes. But what is the benefit of seeing them?

[HanabishiRecca]

In short, yes - a "hash of hashes". We can display such "pieces root" hashes. But what is the benefit of seeing them?

In that case, there is no practical benefit, I think. As you don't have any reference to compare it with. Also the resulting hash is different for torrents with different piece sizes, despite the actual content being identical. Which makes the whole thing pointless.

But all that has nothing to do with OP's idea of showing actual file checksums anyway. I.e. sorry @memoryhash, but your idea is impossible to implement with current BitTorrent v1 and v2 protocols.

[glassez]

Also the resulting hash is different for torrents with different piece sizes, despite the actual content being identical

These hashes are independent of the piece size.

[mirh]

This is apparently possible with v2 (and some torrents supposedly can come with a md5sum field).

These hashes are independent of the piece size.

Aren't hashes per-piece?

[HanabishiRecca]

This is apparently possible with v2

It is possible of course. But users usually want to know an actual hash of the file content, not the internal hash of the tree.

Aren't hashes per-piece?

Apparently not. From the spec:

pieces root For non-empty files this is the the root hash of a merkle tree with a branching factor of 2, constructed from 16KiB blocks of the file.

I.e. the hashes appear to be always calculated from fixed 16KiB blocks, regardless of the piece length.

[xavier2k6]

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future! Here are some options available to you:

1. Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.

2. Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket. (new/existing contributors/developers are always welcome)

---

DO:

• Provide constructive feedback.
• Display how other projects implemented same/similar etc.

DO NOT:

• Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). (These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)