Adding the ability to encode/decode to/from Base64 and Base32

[asahaf]

I've found myself encoding the UUID to Base64 and Base32 string in multiple projects I worked on. Do you think it's a good idea if we add this encoding and decoding to this library or that's out of its scope? Thanks

[zerkms]

What's the use case? I personally never seen it encoded anything but binary or hex-string.

[asahaf]

One use case is when I use UUIDs in URLs. Base64 produces shorter string representation. in case I need shorter case-insensitive UUID string I use Base32.

[cameracker]

Equivalent functionality is https://www.npmjs.com/package/short-uuid

[dylan-bourque]

Personally, I'd argue that this would be an unnecessary extension, since it would essentially be 1-line pass-through calls to base64.UrlEncoding.EncodeToString(u.Bytes()) and base32.StdEncoding.EncodeToString(u.Bytes()).

[wolfeidau]

I have a wrapper which uses base58, a handy middle ground which is used widely https://github.com/wolfeidau/shortuuid, as you say it is a pretty simple wrapper around existing UUID libraries.

Keen to migrate this to this library so i can try out v6 UUIDs.

[cameracker]

Doing a little research on the topic, I think we should use base58 as is done with @wolfeidau's package.

Similar to Base64, but modified to avoid both non-alphanumeric characters (+ and /) and letters that might look ambiguous when printed (0 – zero, I – capital i, O – capital o and l – lower-case L). Base58 is used to represent bitcoin addresses.[citation needed] Some messaging and social media systems break lines on non-alphanumeric strings. This is avoided by not using URI reserved characters such as +.

https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58

[dylan-bourque]

I think Parse() could be extended easily enough to accommodate decoding base58/base64/base32 strings without disrupting existing functionality, but String(), Format(), and MarshalText() all have established behavior and adding a new Base58String() method feels clunky.

[cameracker]

I agree on the clunkiness and the potential verbosity of maintaining a bunch of permutations of different base values. How would you feel about a pair of functions that worked like String() and Parse() and we just be opinionated about it being base58?

Short() FromShort()

[dylan-bourque]

I don't really like Short()/FromShort(). Those names feel obtuse to me and would obviously need documentation to clarify what they do. If we pick base58 then I would go with explicit Base58String()/FromBase58String(). It's clunky but it's also obvious and unsurprising, which I think is more important for a library like this.