Very early on ODF adopted base58btc encoding, simply mimicking other projects like Bitcoin, IPFS, and did:key W3C spec. But this encoding is problematic:
It can result in text that resembles words, potentially resulting in swear words in hashes and DIDs
It’s hard to write down or read out as many letters and numbers can look similar
Its lexicographic order does not match the sort order of binary data
It doesn’t work with subdomains (RFC1035, RFC1123) that are restricted to: case-insensitive, a-b0-9 and less than 63 bytes.
The latter issue is especially important to allow exposing datasets and their attachments in a similar way to IPFS gateways, where subdomains are needed to ensure HTTP origin security.
Compatibility: Declaring that we support multiple multibase encodings instead of just one may slightly complicate compatibility between implementations, but since multibase is a self-describing format these issues should be easily addressable. This approach also has additional benefit of upgradability.
Increase of length: For an implementation choosing to stick with base16 recommendation the main drawback is the increase of length of hashes in:
file and directory names
human-readable formats
presentation layer
Because the binary representation is unaffected we don’t see this as an issue.
did:key compatibility: did:key spec currently only allows base58btc encoding. By using base16 in did:odf, we will have to transcode the DIDs when passing them to frameworks that work with did:key. The main drawback is that developers will not be able to visually compare or search by a did:key that, for example, appears in an auth token, without performing conversion first.
We believe accept this issue while expecting that:
Most places that accept did:odf (e.g. API endpoints) can perform transcoding automatically
The choice of base58btc in did:key method will be reconsidered as per this open issue, potentially opening did:key up to supporting multiple multibase encodings.
base32hex encoding is case-insensitive and maintains sort order - dismissed as it can still form obscene words
Crackford’s base32 encoding avoids letter/number similarity and excludes ‘U’ to reduce likelihood of accidental obscenity - dismissed as not yet supported by the multibase spec
Start Date: 2023-12-14
Authors:
Compatibility: