Hacker News Reader

Comment by sedatk | Hacker News Reader

I don't get the use case. We already have Base32. We already have human-readable Base32 (Crockford's flavor). And Crockford makes the better tradeoff by addressing I/1/l ambiguity instead of U/V. We don't need a new hex format either. I don't get why this exists.

View on HN

> And Crockford makes the better tradeoff by addressing I/1/l ambiguity instead of U/V.

Exactly!

It is much easier to mistake "l" for "1" (lowercase L for number 1) than "5" for "S" or "U" for "V".

Crockford doesn't have U in its alphabet so it doesn't have U/V problem either. It just doesn't have aliasing for U because it's used for check digits.

At least they document the tradeoffs with comparisons to other encodings.

https://base32h.github.io/comparisons

So, according the document the only difference is Base32H solves ambiguity between S and 5 but allows ambiguity between l and 1.

I think that's the worse tradeoff to be made, let alone a reason to create whole another encoding scheme.

> allows ambiguity between l and 1

It doesn't really. The canonical is L (uppercase). In practice lowercase l will never appear, unless for some reason you want it to (you could convert L05ER to l05ER just for presentation, there are worse leetspeek offensive terms that would be allowed though).

Also the U/V thing neatly gets rid of FUCK. S/5 and I/1 take care of others.

I wouldn’t want ALLUPPERCASE identifiers on my URLs for instance. I presume that would be one of the most common scenarios it would be used in.

Well, it will still work but you'll lose the benefit of it.

Most of these don't look like SHOUTING to me. They look uppercase but not aggressive.

You don't want upper-case in URLs for social reasons. It simply looks out of place, takes more screen real-estate, and stands out unnecessarily.

I'm just saying, if canonical is good enough, "S/5" fix isn't sufficient to get a whole new standard then. If it isn't good enough, then the value this one promises over Crockford is arguable due to lack of I/l/1 aliasing.

I downcase all ids, sometimes this includes uuids and string ids.

This is suggesting that you don't.

It shouldn't be that hard to start using it in the canonical form - just start treating IDs as if they're case sensitive.

> I think that's the worse tradeoff to be made

That's definitely a fair conclusion. If you're using lowercase identifiers, then I agree wholeheartedly, and you'd be better served by Crockford's (or perhaps some Crockford/Base32H hybrid that aliases L/l to 1 and de-aliases S/s from 5).

What motivated me to make that tradeoff was two-fold:

1) For my use-cases, identifiers were/are always uppercase by default (and indeed, the Base32H specification requires encoders to emit uppercase-only), which eliminates ambiguity between L and I/1

2) Smudges and grime and scratches and such can and frequently do make it difficult to distinguish S from 5 or V from U; it was therefore a pragmatic choice to alias those (while preserving Crockford's partial profanity defense as a nice side-effect)

That's fair and what you say makes sense in that context. Crockford doesn't have U/V problem either by the way, because it doesn't have U in its alphabet. It's only missing aliasing for it, so there is no possibility of passing on the wrong value by confusing V with U.

That just leaves 5 and S. Whole another standard just for that might be acceptable if the use case you mentioned (mostly upper-case) gets significantly more benefit from it.

There's also "Bech32" from the Bitcoin world: https://en.bitcoin.it/wiki/BIP_0173#Bech32

The cool thing about using a standard Base32 representation is there's so many to choose from!

something something xkcd 927 something something

(Though in my defense I'm under no illusion that Base32H satisfies everyone's use cases)

Or that Base32H satisfies anyone's use cases...

Haha, fair enough.

Reply on news.ycombinator.com