Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC Spec Draft #41

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

RFC Spec Draft #41

wants to merge 2 commits into from

Conversation

jbenet
Copy link
Member

@jbenet jbenet commented Aug 14, 2016

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.

@msporny
Copy link

msporny commented Aug 10, 2018

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?

@ghost
Copy link

ghost commented Aug 10, 2018

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.

@ghost
Copy link

ghost commented Aug 10, 2018

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
Copy link

@ghost ghost Aug 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link

@ghost ghost Aug 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

@ghost ghost Aug 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Muvint is a relatively new term -- in most places we've called these unsigned-varint or simply varint.

ambiguity.


## Considerations
Copy link

@ghost ghost Aug 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another considerations section could be about the use of multihashes in hostnames and URLs.

@msporny
Copy link

msporny commented Aug 10, 2018

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)?

@ghost
Copy link

ghost commented Aug 10, 2018

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

Yeah that's correct, and sounds good to me!

@jbenet
Copy link
Member Author

jbenet commented Aug 10, 2018

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.

@Stebalien
Copy link
Member

Stebalien commented Sep 19, 2018

As pointed out by @arnau, we need to fix the codes for blake2*: #100

@nichtich
Copy link

nichtich commented Apr 7, 2019

The spec is being worked on at https://github.com/w3c-dvcg/multihash so this pull request should be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants