W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: Use of Base58 in technical specifications

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 26 Apr 2020 10:50:02 -0400
To: public-credentials@w3.org
Message-ID: <98dd019d-6034-76f3-97bb-988bbaef11ad@digitalbazaar.com>
On 4/24/20 3:59 PM, Orie Steele wrote:
> If you want to never be misinterpreted, never use the term "base58"
> without saying "with the bitcoin alphabet" :) ... but it's likely that
> when you hear base58, you can assume "with the bitcoin alphabet".

I agree with much that has been said about base64* in this thread...
it's a mess (a useful mess, but still, a mess). I was just battling a
"secretly not base64, secretly not even unpadded base64, really
base64url, even though the docs say its base64" bug in some code on
Friday... and that bug only appeared after running several hundred
variations of input data into the algorithm I was writing.

Note that in:

https://tools.ietf.org/html/draft-msporny-base58-01

There is only one alphabet. That is, while the Ripple and Flickr
alphabets are acknowledged, they are relegated to just Ripple and Flickr
applications because we don't want to fall into the same trap that
base64 did.

The spec above asserts: There is only one globally interoperable
alphabet for base58, all implementations should use that one.

I realize that this is going to cause heartburn in the various Ripple
and Flickr communities, but saying "You can choose among N alphabets"
harms standardization, especially in this space. The Bitcoin alphabet is
the one with the most wide spread usage... that's the one we standardize
on and move forward.

As a standards community, we need to drive this point home with
implementers if we want something that's going to not result in
fragmentation, like base64 did.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Sunday, 26 April 2020 14:50:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC