3 ms·

"just the cryptographic hash of that file" Is that strictly true? I am still wrapping my head around the DAG, but as far as I can tell, if I add a "large" file

• chriswarbo 8y ago
  You're right that it's slightly more complicated than e.g. `sha256sum < myfile`. I would claim it's still "just the cryptographic hash of that file", albeit via a slightly more complicated algorithm than raw SHA or MD5 or whatever. Files get split into "blocks" of raw data of a certain size (e.g. 64k), and each of these is hashed to get its ID. Blocks don't have to store raw data, they can instead store references to block IDs, i.e. "concatenate the blocks with the following hashes: 12345 abcde vwxyz ...". Those blocks are also hashed to get their ID and can be referenced by other blocks, and so on. The first type of block (containing raw data) acts as storage. The second type of block (containing references) tells us how to reconstruct our files. The reason IPFS does this is to increase the chance that data can be deduplicated (for example, if we upload a new version of our blog, the unchanged pages can reference the same blocks as the old version) which makes storage more efficient (with a logarithmic cost for storing the blocks of references). It also makes the storage more resilient, since blocks that appear in multiple files (or multiple version of a file) are more likely to be served by more people. It also allows downloads to be performed in parallel, since we can get some blocks from one person and other blocks from someone else. This splitting-up-and-referencing process is deterministic, so people uploading the same file will get the same hash. However, there are options which we can change from the defaults, which will cause the hash to differ; for example if we pick a different block size or hashing algorithm. Files can also be added in a "streaming mode", which will also result in a different hash than adding in the default way. AFAIK streaming mode makes it easier to pick blocks from the start of a file (e.g. so we can buffer the first X% of a video file, rather than fetching X% of the blocks from all over the file in whatever order our requests happen to come back in) > Can I hand someone a 16cb96ba835448d441b02c50d783a0ea7b424df1 and expect them to be able to find the file? That's not a valid IPFS hash (e.g. https://ipfs.io/ipfs/16cb96ba835448d441b02c50d783a0ea7b424df1 https://ipfs.io/ipfs/16cb96ba835448d441b02c50d783a0ea7b424df... doesn't work). If you send that file to `ipfs add` (or `ipfs add -n` to only get the hash and avoid actually serving it), you will get a hash that anyone can attempt to fetch. Those attempts should work, as long as someone (possibly you, possibly anyone else) is serving that file (just like with HTTP; although multiple people can serve it and no permission is required, unlike the single IP/domain of HTTP identifiers)