RFC-012: Recommend `base16` encoding for textual representation of hashes and DIDs
Start Date: 2023-12-14
Proposes to expand the spec’s support to all
multibase encodings but recommend
base16 as default choice for representing hashes and DIDs.
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-9and 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.
The proposal is to:
Specify that ODF implementations must support all multibase formats in
finalstatus of approval process, performing transcoding where needed.
Recommend new implementations to use
base16encoding (RFC4648) where possible to avoid the pitfalls described in motivation section.
did:odfmethod specification to use
base16encoding too, while allowing to transcode to
base58btcfor compatibility with
This change will be executed as part of the backwards compatibility breaking changes.
Compatibility: Declaring that we support multiple
multibaseencodings instead of just one may slightly complicate compatibility between implementations, but since
multibaseis 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
base16recommendation 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:keyspec currently only allows
base58btcencoding. By using
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:keythat, 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
did:keymethod will be reconsidered as per this open issue, potentially opening
did:keyup to supporting multiple
base32hexencoding 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
- Related IPFS tickets: