Support Nix base32

[griff]

Would supporting the variant of base32 that Nix uses be something you would consider?

It is like LeastSignificantFirst but reversed:

let mut spec = Specification::new();
spec.symbols.push_str("0123456789abcdfghijklmnpqrsvwxyz");
spec.bit_order = BitOrder::LeastSignificantFirst;
let encoding = spec.encoding().unwrap();
let mut actual = encoding.encode(&hex!("0839 7037 8635 6bca 59b0 f4a3 2987 eb2e 6de4 3ae8"));
unsafe { actual.as_bytes_mut() }.reverse();
assert_eq!("x0xf8v9fxf3jk8zln1cwlsrmhqvp0f88", actual);

[ia0]

Thanks for the request! This base32 variant is an interesting one. It makes very little sense to me to design such a thing and I'm curious of the decisions that lead to this choice.

The library as of today is meant for "streamable" encoding (i.e. possibly unbounded/infinite), which is why it's only base2, 4, 8, 16, 32, and 64 (and not for example base58). This Nix base32 does not fulfill this condition (although it's a base32, which is what I find crazy) and is thus impossible to support with the current design, i.e. there can't be a NIX_BASE32 of type Encoding.

I'm not sure I want to support such encodings at the moment, but this could be an option for the v3 which I want to eventually release (but might take some time). If I do support this, it would be a different engine meant for short inputs. And then it would be possible to support all other binary-to-text encodings. That would be a big change though and maybe better for a different crate. I'll sleep on it while working on v3.

Thanks again for bringing this to me! But don't expect anything soon or even at all.