Haha, you’ve got it backwards.
With a merkle tree, I can download a tiny chunk of a file and still verify it’s part of the correct file.
Without a merkle tree, I have to download the entire file before being able to verify its hash… If the file takes a long time to download and you only find out it’s the wrong hash after you finish downloading, then you’ve suffered a delay attack & need to restart the entire download.
Yes, but if and only if you already know the merkle tree structure, no? If I’m looking at an old Nostr note and want to find the image it had in it now the original URL is dead, and only have the whole file hash, I wouldn’t know what the merkle root hash is. Pretty easy to solve by having both hashes available, but it is a slightly different problem
No, you can request a photo with its merkle root on nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g just like you can request a photo with its hash on blossom.
If you are missing file chunks, you specify the leaf numbers you are missing. Each leaf is labeled with a number. Total number of leaves are within the merkle root block.
This^ missing file chunk retrieval process is performed automatically — users don’t need to think about it. Was just describing how it works under-the-hood.
I don’t think supporting a whole file hash is a good idea. Files should be chunked. We’re not going to support both ways. It’ll be backwards compatible with the original method of centralized website, and with merkle roots. Blossom is the wrong path.
