search

multiformats / multihash

Self describing hashes - for future proofing
https://multiformats.io/multihash/
MIT License
883 stars 112 forks source link

Loggable stringified version #47

Open jbenet opened 7 years ago

jbenet commented 7 years ago

In writing CID i wanted a way to expand a CID into a human readable log version, for development. So i wrote this:

This means multihash needs an equivalent version.

@greglook already wrote one over at https://github.com/multiformats/clj-multihash it looks like:

hash:sha2-256:dbd318c1c462aee872f41109a4dfd3048871a03dedd0fe0e757ced57dad6f2d7

My comments on it there: https://github.com/multiformats/clj-multihash/issues/7

jbenet commented 7 years ago

Relevant comments from: multiformats/clj-multihash#7

I would discourage use of : end prefer - because it would be great if people use the compressed representation in URNs instead of the expanded one... but i can be persuaded.

(I would want to ensure people don't use the string versions to rely on them for identifiers-- as the whole copy-pastability and versatility of multihash goes down with that).

See also

ghost commented 7 years ago

I like it generally! Nitpicks:

ghost commented 7 years ago

I agree about : as a delimiter being less than ideal, but so is -, since it already clashes in the simplest example with sha2-256 :) In the context of URNs, & or ; might fit?

On the other hand we're talking about a human-readable version, where this is less of an issue.

greglook commented 7 years ago

I agree about : as a delimiter being less than ideal, but so is -, since it already clashes in the simplest example with sha2-256

This was the reason I used : in the URN form, otherwise you can't easily tell whether -256 is part of the algorithm name or a different field in the multihash.

greglook commented 7 years ago

We might wanna consider a less general prefix, e.g. mhash or multihash

This would also be good - as far as I could find at the time, there was no real accepted standard for the hash URN namespace, so I went with the simplest version I could think of.

jbenet commented 7 years ago

i wouldnt be against claiming the hash: prefix -- particularly since our goal is to make it easier to work with many hashes and we would commit to being good stewards of the namespace -- but we may have to put a real bid for it and be ready to change it if it doesn't fit

jbenet commented 7 years ago

Ok, I'm okay with :

jeremyBanks commented 5 years ago

The mutliformats home page says

They MUST have a human-readable representation.

Was a human-readable representation ever standardized for multihash?

Stebalien commented 5 years ago

I don't believe it has ever been finalized.

nichtich commented 5 years ago

See this independent draft which could be defined on top of multihash specification instead being part of it. Note that the digest length is implicitly given by the length of the string, we only need to agree on canonical hash function names in addition to the hash function identifiers.

Fak3 commented 5 years ago

There is also https://github.com/w3c-dvcg/hashlink spec, which leverages multihash to make uris

ben221199 commented 1 year ago

At https://multiformats.io/#what-are-multiformats there are some stipulations:

The last 2 are important. At the moment I am aware of the binary representation of the multihash, however, I didn't see any human-readable representation. Is this issue about adding that human-readable representation?

Also, I see you guys talking about reserving hash: or something, but why not just go with #? THE HASHTAG!!! For example, #sha2-256:dbd318c1c462aee872f41109a4dfd3048871a03dedd0fe0e757ced57dad6f2d7.

nichtich commented 1 year ago

@ben221199 The hashtag is used in URI syntax for referencing content within a document, so using multihashes in this context makes no sense. A human-readable representation should also be a valid URI to be used as identifier where URIs are required (e.g. RDF), but the hastag has nothing to do with it.