Ipfs urls and rfc 6920

Ecosystem
1

I know there has already been some discussion about assigning urls to hashes such as ipfs:// ifns:// and dweb:// but has anyone suggested or looked into using RFC6920 named hash urls? It’s a standard and seems to fit well with IPFS.

2 Likes
2

While I cannot tell you whether anybody has previously looked at RFC6920, I may be to give you an idea how they compare to the existing IPFS concepts:

First of all, the ni:///-URIs described in RFC6920 are a way to reference pieces of formatted binary data using a hash. In other words, comparing it IPNS is obviously meaningless since they are unrelated concepts – only the comparison with IPFS appears to make sense on first glance. Looking closer however we see that IPFS imposes further restrictions on the data referenced (UnixFS) to provide something resembling classical filesystem using the referenced bits of data.

With CIDv1 this is not strictly true anymore, since it is possible to create “raw hashes” that directly reference bags of bytes. As such the following URIs are basically identical in their meaning:

  1. dweb:/ipfs/f015512204df3c3f68fcc83b27e9d42c90431a72499f17875c81a599b566c9889b9696703
  2. ni:///sha-256;TfPD9o_Mg7J-nULJBDGnJJnxeHXIGlmbVmyYiblpZwM

Notice how the “hash” in IPFS carries extra meanings since its actually a CID:

  • “f” is the multibase prefix for the “base16” encoding – RFC6920 mandates base64url, in this case I converted the value to base16/hex for better illustration
  • “01” means CID version 1
  • “55” is the multicodec value for “raw binary” – RFC6920 implicitly mandates this for all hashes (you can specify a media type, but the hash will always refer to some complete file)
  • “12” is the multihash value for “sha-256” – RFC6920 also allows varying the hash function
  • “20” is the length of the an sha-256 hash
  • The remainder is the actual hash value

From this we can see that ipfs://-URIs (at least when using CIDv1) are a strict superset in what they can express, compared to ni:///-URIs. While it might not be terribly obvious from the above, that single “multicodec” byte is what makes all the difference here: Depending on its value it can impose further structure on the referenced data (such as being of type “dag-pb” aka UnixFS), thereby allowing things like path-traversal for which RFC6920 simply does not have any equivalent at all (you always need to specify the hash of the actual piece of data referenced).

This was not actually a discussion on whether we should actually use RFC6920, simply pointing out how it relates to what we already have. Hopefully you find it useful.

(Had to scrape all the links from my post due to stupid restrictions.)

3

Thank you for the great information. Looks like this falls a little short.