What about Base62?

[Pitometsu]

Aka alphanumeric [0-9A-Za-z].

[ribasushi]

Could you elaborate on the benefits of adding support for this codec?

Multibase sits at a rather pivotal "entrypoint" in the decoding process: adding additional encodings carries implementation costs to each individual language/library. Some already unilaterally decided not to support the full gamut: richardschneider/net-ipfs-core#54

If anything we are considering dropping some of the entries: #59 (comment)

[Pitometsu]

Perhaps I missed the goal as full base-like encoding coverage. Closing this then.

[mikeal]

We want to try and capture all commonly used base encodings, so we should figure out the best way to support this.

It is true that today some multibase implementations ship with every encoding but as far as I’m concerned this is a bug. The new js-multiformats stack can ship with zero base encodings or even table information about each encoding.

However, one thing we need to worry about here is preserving namespace. We have a much more limited space we’re working with (single character) than multicodec so we do need to worry about adding encodings that are rarely used.

[ribasushi]

We have a much more limited space we’re working with (single character)

Well... that is definitely fixable: we just take out a character pair (in order to allow for case insensitivity) and designate it a multi-character prefix akin to how country-code dialing works

[mikeal]

i know, but it means we increase the space taken up by the metadata at a much faster rate than varints.

i’m also a little worried about using up the entire set because you’ll never see failures in parsing something that wasn’t actually multibase encoded.

[vmx]

We want to try and capture all commonly used base encodings, so we should figure out the best way to support this.

Is GitHub issues the right way to track this? There are already so many issues open about other codecs. Would it make sense to create a file that contains the information from those issues?

[mikeal]

@vmx I think this (base encodings) is a little different than codecs. There isn’t a gigantic list of prior formats to consider, nor do we expect the list of base encodings to grow a lot over time, and the multibase table is separate (do we have a proper table yet?) from the multicodec table.

[vmx]

@mikeal sorry, I meant to write "Base encodings" instead of "codec".

nor do we expect the list of base encodings to grow a lot over time

We have at least 13 issues open about potential Base encodings. I would rather close all those and put them into a file. I don't mean to support those encodings, so it shouldn't be a table with supported codecs, it's just a matter of tracking it in a better way that cluttering the issue tracker.