Re: Adopting the Multihash spec as a work item?

On Thu, 3 Jan 2019 at 20:30, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 1/2/19 2:22 AM, Melvin Carvalho wrote:
> > Does not RFC 6920 (Naming things with hashes) already have this
> > property
>
> Yes, it is one of the properties that spec has.
>
> > https://datatracker.ietf.org/doc/rfc6920/
>
> The argument is that the specification above did not do proper
> architectural layering. It combined 1) hash algorithm specification, 2)
> URLs, 3) base-encoding, and 4) dereferencing protocol into a single
> specification instead of layering the architecture in the appropriate
> way, like the following stack (high to low order):
>
> URL encoding format
> agile base encoding
> agile hash expression
>

So I think they just went with a readable base64 for all.  Which I think it
makes sense to just have one, unless we need more?

It could be argued in 2019 we need more, to cope with more crypto systems,
or to perhaps embed stuff in a block chain.

Then the layering approach works.  Is there such motivations?


>
> ... where the dereferencing protocol should have been outside of the
> specification to enable the URLs to support multiple network protocols.
>
> By splitting the spec into these different parts (multihash, multibase,
> and hashlink), we enable those building blocks to be used elsewhere
> (e.g. public key expression)... and enable new use cases (multi-network
> support).
>

Well there's a neat dereferencing system using .well-known/ni/

Again that keeps it simple without requiring extra complexity, unless that
has become a new requirement.


>
> > And furthermore, has the advantage of a way to dereference the hash
> > using HTTP.
>
> The hashlink spec has the same advantage, but isn't tied to a single
> network protocol like the ni:/// format is AND has a native packed
> binary representation.
>

Sure it does add complexity though where ideally we could just use
hexbinary or base84 if people could agree.  I think what you're saying is
that is unlikely.


>
> > Are there any substantial advantages to the multiformats RFC?
>
> Yes, explained above... do those arguments resonate with you, Melvin?
>

Yes it does!

So the concern is that there is a lot more complexity which is an issue
when trying to gain adoption.

What do you think about, in that case, adding "multihash" as one of the
hash algorithms inside RFC 6920

If that intent is stated, then we could start using multihash on the web
productively today (something I've wanted to do for ages) -- would that be
feasible?


>
> -- manu
>
> PS: We had been using ni:/// heavily until we shifted to the approach
> listed above.
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>