- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 3 Jan 2019 14:30:18 -0500
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
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 ... 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). > 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. > Are there any substantial advantages to the multiformats RFC? Yes, explained above... do those arguments resonate with you, Melvin? -- 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:30:45 UTC