- From: Nikos Fotiou <fotiou@aueb.gr>
- Date: Wed, 10 Mar 2021 23:08:25 +0200
- To: Credentials Community Group <public-credentials@w3.org>
- Message-Id: <349D912D-B516-4796-B60C-F923680042C3@aueb.gr>
Hi all, To begin with I want to clarify that I do not want to discredit anybody: I am big fun of the work of both Digital Bazaar and Protocol Labs. I would like to share with you my frustration about did:key and in particular its use of MULTICODEC. All started when I tried to understand why Ed25519-based DIDs start with z6Mk. z is obvious, it means base58 in the MULTIBASE world, but 6Mk was still a mystery. The entry for "Ed25519 public key" is the "Mutlicodec table" (https://github.com/multiformats/multicodec/blob/master/table.csv) is "0xed" So how come "0xed" is translated into "6Mk"? It turns out that MULTICODEC uses an uncommon way for storing integers called "varint" (https://github.com/multiformats/unsigned-varint)! Using this encoding "0xed" is translated into two bytes. What is worse this type of encoding is not natively supported by mainstream languages and you have either to rely on an external library or start playing with bits in order to use it! Of course, when it comes to real systems, you realize that all these are useless and people just use hardcoded values of the ordinary bytes eventually formed (see for example https://github.com/transmute-industries/did-key.js/blob/c1bef568ad9afd703ba9ac3d42b919ccfdf10aee/packages/did-key.js/src/resolver.ts#L7) So what would be a better way for doing the same thing? Just use a byte to express "length in bytes" and then use up to 255 bytes to encode what ever you want. This is what CoAP and other binary protocols do. It would take only 3 bytes and less than 5 lines of code in any language to encode any entry currently included in the "Mutlicodec table". Best, Nikos -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 10 March 2021 21:08:42 UTC