Re: Adopting the Multibase spec as a work item?

Manu, can you also add this as an issue under so we can track it? (Joe and
I are puzzling over best processes for work items).

https://github.com/w3c-ccg/community/issues

Right now I hope to schedule discussion on this for January 15th W3C
Credentials CG meeting.

-- Christopher Allen

On Tue, Jan 1, 2019 at 10:34 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hi all (bcc: Protocol Labs Research Division),
>
> This email is about *Multibase*, which shouldn't be confused with
> *Multihash* (what the previous email was about).
>
> The Multibase specification was just published a few days ago as an IETF
> Internet-Draft. The specification is intended to be a joint work product
> of Protocol Labs (IPFS and Filecoin), the W3C Digital Verification
> Community Group, and the W3C Credentials Community Group. Just as with
> Multihash, we need to decide if we're adopting it as a Work Item in
> the CCG.
>
> So, what problem does Multibase solve and why do we care?
>
> Multibase is the same sort of concept as Multihash, but for binary data.
> Our community encodes binary data in things like DID Documents and URLs.
> For example, both the Veres One and Sovrin DIDs encode the public key in
> the DID itself (these are legacy DIDs from past development versions,
> and are provided for illustration purposes only):
>
> did:v1:test:nym:z279ikfef3QbKRgnvTFmq5wEzZpe7s4fBiMb97hSEezXv3SL
> did:sov:WRfXPg8dantKVubE3HX8pw
>
> That bit at the end there is binary data (the public key) that is
> "base-encoded" so that it's easy (for developers) to copy/paste that
> stuff around and put it in emails when talking about technical things.
> The problem is the same as the one Multihash solves... how do we know
> what base-encoding format was used above (base64 with padding,
> base64url, base58btc)?
>
> To solve this problem, we add a single byte to the beginning of the
> encoded value, so this:
>
> did:v1:test:nym:279ikfef3QbKRgnvTFmq5wEzZpe7s4fBiMb97hSEezXv3SL
>
> turns into this (note the addition of 'z', which means "the data you are
> about to read is encoded in Bitcoin's base-58 encoding"):
>
> did:v1:test:nym:z279ikfef3QbKRgnvTFmq5wEzZpe7s4fBiMb97hSEezXv3SL
>
> This is useful because this mechanism allows us to encode the same
> information in a variety of different ways. For example, Ethereum folks
> tend to use base16lower encoded values for their addresses while Bitcoin
> folks use a Bitcoin flavor of base58. At some level, these are sort of
> arbitrary decisions that developers fight over, but with Multibase, the
> decision is translated into a simple matter of value conversion. You
> don't have to fight over the base encoding format because Multibase
> encodes it in the resulting value, making conversion simple and
> deterministic and enabling future upgradability for your system (and
> compatibility with other systems).
>
> Multibase also allows developers to change the encoding format at a
> later date because the software was written with upgradability in mind
> from the beginning. The spec is a fairly short one, weighing in at 7
> pages and can be found here:
>
> https://tools.ietf.org/html/draft-multiformats-multibase-01
>
> This email is a request to the Chairs to add this to the next meeting
> Agenda and for the CCG and adopt it as a work item.
>
> -- manu
>
> --
> 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
>
>