[mtmail]

"encodes UUIDs to a readable Key format via the Base32-Crockford codec and also decodes them back to UUIDs."

Example: "d1756360-5da0-40df-9926-a76abff5601d" => "38QARV0-1ET0G6Z-2CJD9VA-2ZZAR0X"

I think now you risk having 0 vs O or I vs 1 readability issues. [edit: good news, I was wrong]

[notpushkin]

Base32-Crockford doesn’t have 0 and 1 for this exact reason!

(Seems uuidkey authors have decided to remove O and I instead, but the effect is the same)

EDIT: I’ve looked it up and I was wrong! Crockford alphabet does use all digits (0–9), but doesn’t have O, I or L. When decoding, O is mapped back to 0 and both I and L are mapped to 1. Sorry for the confusion!

[mrweasel]

Given that API keys are likely to simply be copy-pasted, I don't honestly think this matters all that much.

If you're have the risk to users confusing 0 and O, then you can't use either. Your users aren't going to know that you're running Base32-Crockford and that they'll only encounter 0 and 1, never O, I or L.

We did a "password" generator, for people who made a purchase, but didn't want an account. To view an order they'd then need to enter a code, found in their confirmation email. Those codes where really short, 8 or 10 characters, no 0,1,I,O,L,U,V and all upper case. If the user entered the code in lower case, we'd automatically upper case it. You'd never use these as a real password, but for a temporary order tracking page they pretty much removed all of the input mistakes people could make.

[notpushkin]

> Given that API keys are likely to simply be copy-pasted, I don't honestly think this matters all that much.

Yeah, I think it’s not that important for API keys particularly. It’s possible that some IDs would be spoken over a phone for example, but it’s probably rare.

> If you're have the risk to users confusing 0 and O, then you can't use either. Your users aren't going to know that you're running Base32-Crockford and that they'll only encounter 0 and 1, never O, I or L.

The way Crockford got around that was, OIL are allowed when decoding the string (and just replaced by 0 and 1 accodringly). So if used mistypes O in place of 0, it’s still going to decode just fine. I think it should work alright for stuff like license keys or “passwords” like in your case (although your solution works too!)

[copperlight]

https://www.crockford.com/base32.html

> We chose a symbol set of 10 digits and 22 letters. We exclude 4 of the 26 letters: I L O U.

I had never heard of Base32 Crockford before. The whole rationale is clever.

[zdc1]

I feel like they really missed the mark with "Beautiful" as their priority. If I were to make a UUID to API key encoding/serde library I'd definitely prioritise things like human readable characters / phrases (e.g. BIP-39 style with hyphens), and as jjice said, a fixed prefix.

Edit: okay, good to know were at least covered for 1 vs I issues.