From @MarkusTeufelberger on Fri Jan 20 2017 22:15:01 GMT+0000 (UTC)
An example would be a file that’s hashed with 2 different algorithms or a large file that - if reassembled - has the exactly same content, but has been split up in different individual parts using different algorithms.
Bittorrent suffers from this issue for example, as the creator of the torrent file can choose the block size which in the end leads to different info hashes for the exact same file. This is slightly reconciled in the metalink file format, where one can specify a lot of different sources for the same file. My question is if there’s something similar to metalink for IPFS too, to tell others that 2 completely unrelated addresses actually result in the exactly same content and thus can be used interchangably.
From @MarkusTeufelberger on Sat Jan 28 2017 12:44:35 GMT+0000 (UTC)
And apparently denied in https://github.com/ipfs/notes/issues/89 (at least for IPFS, which is intended to address a certain graph layout on top of some content, even if the underlying content is the same).
There might be hope for 2 outcomes: A canonical/recommended setting to create IPFS graphs and subsequently IPFS multihashes or a service on top of IPFS that in a trusted/semi-trusted or maybe even decentralized way provides mappings between different representations of the same underlying content, similar to e.g. metalink.
I would suggest to neglect the metadata practice in favour of single files, just as eD2k, Gnutella and Kad do, and adopt Metalink (RFC 5854).
Suppose that I have tow Metalink files, with some identical files.
If I share data via eD2k by an older Metalink (e.g. with Phex), and I later decide to change the collection and publish a new Metalink with an updated collection, then the older Metalink will not be a requirement to share with people who share the older collection.