multihash
multihash copied to clipboard
Is there an agreed-upon URI and namespace for multihash?
In XML signatures and linked data, one would use a URI for a particular hash function, like http://www.w3.org/2001/04/xmldsig-more#md5
for the MD5 function, and the prefix urn:md5:
to identify a byte stream with its hash (for use in a magnet:
link for example). Sorry if this is not the right place to ask, but are these conventions used here? I have found one instance of urn:multihash:
, so that seems usable enough, but I am clueless about the URI.
One could say that if you already have a way to specify the hash function together with its result, there is not much advantage to using multihash, but not all hashes have existing identifiers, so a way to use its identifier table would be useful.
I guess if a URI is required, it would then just point to Multihash, without pointing to a specific algorithm as the Multihash value itself already contains the information about the hash algorithm.
An urn:multihash namespace would be useful.
It would also be good to include the multibase character.
urn:multihash:<mb><multihash>
@IllidanS4 I raised this same question in the W3C community group on multihash
See these two specs proposed to the IETF:
https://www.ietf.org/id/draft-multiformats-multibase-05.html https://www.ietf.org/id/draft-multiformats-multihash-04.html
FYI: here is the issue I raised:
https://github.com/w3c-ccg/multihash/issues/20
It seems that we could register a mh://
URI scheme perhaps, but this does not take into account multibase and CIDs. Still room for discussion but it would be good to get something stable, nailed down quite soon for those interested in the URI part.
Currently mh:
is preferred slightly to multihash:
as it is more compact. While less descriptive, I think most could live with mh
and it mirrors things like ni
could mh://
just dictate that the following string be a multibase representation of the multihash?
When there's no authority, there shouldn't be a //
, shaving off a few more bytes.