> To download a file over Hypercore, you need to know the content hash. Without the original content hash, you can’t generate the discovery hash, and you won’t

> To download a file over Hypercore, you need to know the content hash. Without the original content hash, you can’t generate the discovery hash, and you won’t know which hash to ask other clients to transfer. Once you’ve found some peers using the discovery hash, you establish an encrypted connection to them and request the content hash. Hypercore (Dat) doesn't use content hashes, it uses ed25519 public keys (which work more like IPNS—the data they refer to can be changed). The discovery hash is a hash of the public key, which isn't sent to the peer as part of the request, it's looked up on the data provider's side using the discovery hash. If the provider doesn't already know the public key then it can't negotiate a successful connection since all subsequent messages are supposed to be encrypted with that key. If the public key (or IPFS content ID) were sent to the peer as part of the request then one could learn the content IDs for "interesting" discovery hashes simply by pretending to have the content, announcing the discovery hash to the network, and waiting for peers to show up and request the data by its content ID. At that point you could request the full content from other peers using the content ID. One could perhaps employ the Hypercore/Dat protocol for IPFS using the content ID for encryption instead of a public key, but it would be critical to avoid revealing the content ID itself as part of the request. Only the discovery hash can be sent to the peer. It might be safer to negotiate a session key with something like SRP[0], with the content ID as the "password". [0] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...