When using this for IdSortable, from 16 bytes, we get a encoded string length of 27 (v00qnlvl084e15mk9inn1en2gno). A higher base like base64 would be nicer as it could give us 23 characters instead.
Obviously what we would like is something that looks like base58btc as it is intended that such ids would be presented to the end user, and but get a guarantee that it is sortable.
Describe the solution you'd like
A human-centered readable encoding for IdSortable that is base64 (it has to be double of base32), that is sortable.
Is your feature request related to a problem? Please describe.
From this issue https://github.com/multiformats/js-multiformats/issues/124, it is clear that the highest sortable encoding right now in multibase is
base32hex
.When using this for
IdSortable
, from 16 bytes, we get a encoded string length of 27 (v00qnlvl084e15mk9inn1en2gno
). A higher base like base64 would be nicer as it could give us 23 characters instead.There are 2 implementations of sortable base64.
Obviously what we would like is something that looks like
base58btc
as it is intended that such ids would be presented to the end user, and but get a guarantee that it is sortable.Describe the solution you'd like
A human-centered readable encoding for
IdSortable
that is base64 (it has to be double of base32), that is sortable.There's no existing standard for this except
uuencode
according to: https://stackoverflow.com/questions/53301280/does-base64-encoding-preserve-alphabetical-ordering#comment101660912_55011262Describe alternatives you've considered
base32hex
is the only viable one atmAdditional context
Expect this to be used by notifications, sigchain and all the places we use
IdSortable
.