Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

github.com

Post reply on HN
Print view View original

181–190 of 236 posts

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#181

Post by ash »

inopinatus wrote: post #159

I'm not wild about the Crockford encoding. In practice I've found it to be a flat-out mistake when you come to provide technical support or analysis for values encoded this way. The Crockford alphabet is based on design goals that are rarely encountered in practice, such as pronouncing identifiers over the phone. It introduces ambiguity, which is a disaster for grepping logs or any other circumstances where you might…

I agree that pronouncing identifiers over the phone is rare. But I’m occasionally typing identifiers from:

1. a screenshot or a screen share that contains an identifier

2. another device where I can’t easily take an identifier

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#182

Post by bongobingo1 »

deanmen wrote: post #88
ajkjk wrote: post #4

Unrelated, but this links to "Crockford's alphabet", https://www.crockford.com/base32.html , which is a base-32 system that includes all alphanumeric characters except I and L (which are confusable with 1), O (which is confusable with 0), and U (????). The page says the reason for excluding U is "accidental obscenity'. What the heck is it talking about?

The F word has a U in it. Sure you could just say FVCK

Or Fwck if you doubly mean it.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#184

Post by EGreg »

mtlmtlmtlmtl wrote: post #111
pluijzer wrote: post #99

Earlier quoted context omitted.

You could argue that U can be confused with V.

A vaguely related historical tangent is that V and U used to be just two ways of writing the same letter in Early Modern English. Which I imagine is why W is named as "double U" in speaking.

Same with B and V, P and F, SS and Z, etc.

It is why PH is F, for instance.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#185

Post by EGreg »

AceJohnny2 wrote: post #94
codeulike wrote: post #48

Earlier quoted context omitted.

If I and O are already excluded and you also exclude U that removes a lot of potential rude looking three letter combinations like *** and *** and *** and also the four letter ones like **** and **** and the dreaded ****. Of course because you have A then **** is still a possibility but very very unlikely

you accidentally the whole thing

I think the point

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#186

Post by deepsun »

bombela wrote: post #13

I have some complaints about UUIDs. Why not just combining time + random number without the ceremony of UUID versioning. And for when locality doesn't matter, just use a 128bit random number directly. And in my experience most people somehow think a UUID must be stored into the human friendly hex representation, dashes included. Wasting so much space in database, network, memory.

The worst thing about dashes is you cannot easily double-click it whole to copy-paste.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#187

Post by AtNightWeCode »

clintonb wrote: post #109
AtNightWeCode wrote: post #25

An important aspect of identifiers is to not leak any information in the identifier. In some scenarios a prefix might be fine but less important things have been blocked by our dpo department.

Requirements depend on the use case. I don’t consider the prefix a “leak” and neither does Stripe.

Yeah and Twitter IDs used to be 32-bit integers. In this case it is kind of obvious that the IDs leaks information about internal data types. Which is not ok at many companies.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#189

Post by tlrobinson »

aartav wrote: post #95

I've been doing this kind of thing for years with two notable differences: 1. I don't believe people actually hand type-in these values, so I'm not really concerned about the 'l' vs '1' issue. I do base 32 without `eiou` (vowels) to reduce the likelihood of words (profanity) sneaking in. 2. I add two base-32 characters as a checksum (salted of course). This is prevents having to go look at the datastore when the valu…

I agree with the addition of the checksum, however I’m curious:

> either by accident or malice

1. if you don’t believe people hand type these then how else will they accidentally enter an invalid? I suppose copy/paste errors, or if a page renders it as uppercase, though you should just normalize the case if it’s base 32.

2. How does a 2 byte (non-cryptographically secure) checksum help in the case of malice?

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#190

Post by tlrobinson »

I really like prefixed identifiers and strongly recommend using them from the beginning.

One question: I’ve seen people use both integer IDs (as the primary key) and prefixed GUIDs (for APIs) on the same table. This seems confusing and wasteful. Is there a valid reason to do that, and is it common? Performance when doing joins or something?

EDIT: it sounds like that’s the reason for them to be “K-Sortable”:

> TypeIDs are K-sortable and can be used as the primary key in a database while ensuring good locality. Compare to entirely random global ids, like UUIDv4, that generally suffer from poor database locality.

Post reply on HN