MD5 (and Metalink) in addition to CID1 (built-in metadata)

Protocol
,
1

Following this question by @MarkusTeufelberger

I would suggest to consider to deprecate the built-in mechanism for metadata in favour of standard RFC 5854 (Metalink).

I would suggest to add an additional hash function which would be utilized only for singular files, and consequently allow the utillization of Metalink (RFC 5854).

If I have a collection shared over IPFS, and then I update the collection, then I would still have to maintain the previous (and obsolete) collection, so I will not lose the peers that still share the files of the previous collection. This is a problem of both BitTorrent and IPFS, and it is not a problem with other P2P networks that assign a checksum to actual files.

In the thread, I have wrote:

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.

2

IPNS is the solution. IPNS (InterPlanetary Name System) | IPFS Docs

IPNS conceptually is comparable to a pointer pointing to an IPFS CID. Republish your IPNS and the same IPNS CID now points to a different IPFS CID.

It’s use does have a couple downsides though. Like publishing could take seriously long, resolving could too if it works at all. The idea is nice but frankly i’d just use a centralized key/value store service where you have a permanent key and you change the value.

Question: What do you mean by “metadata”? Could you link me to some IPFS doc page that describes this “metadata”?

3

A property which is responsible for listing of subject files.

I do not know how it is realized in IPFS.

As an example, in BitTorrent, the Torrent file is a metadata file, which lists subject files.

No. I do not know of it. I need to read the documentation.

4

So you propose to deprecate the metadata when you don’t even know what it is or even if IPFS has it…

If you want to be taken seriously, this isn’t the way.

You should look up the Merkle-DAG, IPLD and UnixFS.
It’s up to you to find those in the docs and read up on what it all is.

Hint: there are many very good videos about these things too which might be more digestible then the documentation.

5

I am still reading the documentations of Merkle-DAG, IPLD and UnixFS.

Yet, by reading about CID versions and particularly CID v1, which, even when it indexes a single file, will always be different than the particular file which it represents.

Hence, My proposal to include an additional (title has changed from “instead” to “additional”) is valid.

Then, I suggest to support MD5 hash which would be treated exclusively for singular files.

MD5 is the most preferable, at least for start, because it is utilized by various of content sharing systems, yet BLAKE3, MD4 or SHA1 should be fine too.

This would make IPFS viable to people of all P2P networks.

I am aware that this type of system, such as eDonkey2000 and Gnutella, is not perfect, yet it works, and in the long term it has proven to perform very nicely .

@daviddias has also made that statement and I suppose that he meant to a similar thing.

https://daviddias.me/posts/publications/2022---to-the-interplanetary-file-systemand-beyond-peer-to-peer-file-sharing-would-make-the-internet-far-more-efficient/

6

5 posts were split to a new topic: IPNS over DHT and PubSub