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

Post by dmurray » Wed, Jun 28, 2023, 10:09 PM UTC

pluijzer wrote: post #99

kibwen wrote: post #64

Earlier quoted context omitted.

> The page says the reason for excluding U is "accidental obscenity'. Crockford is being cheeky. To make a nice base32 alphabet out of non-confusable alphanumeric characters you only need to exclude O, I, and L. This leaves you with 33 characters still, so you need to remove one more, and it doesn't matter which one you remove, so you might as well pick an arbitrary reason for the last character that gets removed (an…

You could argue that U can be confused with V.

Post by avgcorrection » Wed, Jun 28, 2023, 10:14 PM UTC

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?

Post by pphysch » Wed, Jun 28, 2023, 10:20 PM UTC

jeremyjh wrote: post #103

pphysch wrote: post #81

Earlier quoted context omitted.

The latest standard for v7 does not meaningfully describe how to interpret the last segment. It says they could be pseudorandom and non-monotonic. Or it could be monotonic and non-random. These are completely disjoint cases! "X or not X" is tautological. And there is no way to determine which (e.g. there could be a flag that indicates this mode, but there is not). To be clear, the standard should be amended to resolv…

I think the purpose of the standard is so that different software implementations work the same way, so that once you've picked a standard, you can use it everywhere and know that keys are assigned the same way regardless of which software stack is generating a particular key. Its not so that systems can "interpret" it. Obviously they are your bytes to use however you want if you are rolling your own generator.

Post by tasn » Wed, Jun 28, 2023, 10:20 PM UTC

Xeoncross wrote: post #98

tasn wrote: post #63

Earlier quoted context omitted.

We maintain a couple of popular ksuid libraries[1][2] and use it, so we definitely like ksuid. Though one big issue with ksuid is that being 160bit means that it doesn't fit into native uuid types in databases (e.g. postgres), which means that they come with a performance penalty. 1: https://github.com/svix/rust-ksuid 2: https://github.com/svix/python-ksuid

I'm curious, why do you not store these as binary data or do you and you're saying that the UUID operations are better optimized than sorts on binary data?

Post by tomcam » Wed, Jun 28, 2023, 10:34 PM UTC

klabb3 wrote: post #120

A couple of suggestions: Lock down the prefix string now before it’s too late and document it. I see in Go that it’s lowercase ascii, which seems fine except for compound types (like “article-comment”). May be worth looking at allowing a single separator given that many complex projects (and ORMs) can’t avoid them. The Go implementation has no tests. This is very unit-testable. Add tests goddammit! For Go, I’d align…