RFC Spec Draft #41
RFC Spec Draft #41
Conversation
ghost
mentioned this pull request
|
Where are we with this PR for an RFC for Multihash? We (Digital Bazaar) would like to use it for Veres One. Would there be any objections to me picking it up and publishing something at IETF just covering Multihash? |
|
Hey @msporny, your help is very welcome -- we unfortunately don't colletively have much experience with standards bodies yet, which is one of the reasons this PR hasn't moved much. I'd be happy to be your liaison on this. I have much multiformats context and would love to learn some of the IETF processes before pushing for a multiaddr RFC. |
|
What would the first few steps be, and how can I best help? I'll make sure to mark any inaccuracies in this first document here today. |
| Base encoding for strings must be performed around the whole multihash | ||
| value, | ||
|
|
||
| ### Explanation Representation |
There was a problem hiding this comment.
The explanation representation has so far been used very rarely. Instead we almost always simply convert the digest-value to a given base.
In the begining this used to be base58 implicitly, but with IPLD and CID we started using multibase, which prepends a varint signifying the base encoding of the string.
| ### Packed Representation | ||
|
|
||
| The Packed Representation is a compact representation optimized | ||
| for transmitting, storing, displaying, and using multihashes. |
There was a problem hiding this comment.
The packet representation isn't currently intended for display -- see comment under "explanation representation"
| transmission, embedding in other identifiers, or anything other | ||
| than debugging, defeats the purpose of multihash. | ||
|
|
||
| ### MSB Unsigned Varints - muvints |
There was a problem hiding this comment.
Muvint is a relatively new term -- in most places we've called these unsigned-varint or simply varint.
| ambiguity. | ||
|
|
||
|
|
||
| ## Considerations |
There was a problem hiding this comment.
Another considerations section could be about the use of multihashes in hostnames and URLs.
|
Hey @lgierth, thanks for getting back to me so quickly. I think I'll attempt a first rough cut by putting the minimum in the RFC. These specs are such that the less you put in them, the better off you are (as long as the explanation is complete). My assumption is that @jbenet is the person that wrote the most in the multihash specification, so he'll go down as lead editor and I'll put myself as secondary as I'll be editing the IETF specification. Does that work for your team? ... or would you rather have an editor from Protocol Labs (or somewhere else)? |
Yeah that's correct, and sounds good to me! |
|
Hey! thanks for this @msporny -- i think this could work well for everybody. Would be good to coordinate parameters/expectations for success before launching into that work? Then again, Multihash is small enough that the spec shouldn't be too long. |
|
The spec is being worked on at https://github.com/w3c-dvcg/multihash so this pull request should be closed |
This PR begins a draft for an RFC style spec.
There is a LONG LONG way to go for this. This
is only a stab.