- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 3 Jan 2019 20:41:19 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAKaEYhJSBwMMDkwP3HV5P4PNr+MUFpMHA+Zbr1JkwHSPLVGMuA@mail.gmail.com>
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 >
Received on Thursday, 3 January 2019 19:41:53 UTC