4 ms·

"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" =>

by mtmail 2y ago

"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 2y ago
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!
- copperlight 2y ago
  https://www.crockford.com/base32.html 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.
- mrweasel 2y ago
  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 2y ago
    > 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!)
zdc1 2y ago
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.

by mtmail 2y ago

notpushkin 2y ago

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!

copperlight 2y ago
https://www.crockford.com/base32.html 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.
mrweasel 2y ago
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 2y ago
  > 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!)

zdc1 2y ago

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.