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

151–160 of 236 posts

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

#151

Post by kbumsik »

dloreto wrote: post #134
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…

Thanks for the feedback! We have tests for the base32 encoding which is the most complicated part of the implementation ( https://github.com/jetpack-io/typeid-go/blob/main/base32/bas... ) but your point stands. We'll add a more rigorous test suite (particularly as the number of implementations across different languages grows, and we want to make sure all the implementations are compatible with each other) Re: prefix…

> Re: prefix, is the concern that I haven't defined the allowed character set as part of the spec?

It would be great if you add suggestions for compound types (like “article-comment”) in README as OP stated as well.

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

#152

Post by CMCDragonkai »

swyx wrote: post #57

for those researching this topic, I keep a list of these UUID/GUID implementations! https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...

We have a uuidv7 implementation that we've been using with rocksdb for over a year https://github.com/matrixai/js-id

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

#153

Post by bredren »

aftbit wrote: post #143
klabb3 wrote: post #141

Earlier quoted context omitted.

> We have tests for the base32 encoding which is the most complicated part of the implementation I didn’t look into it much but it seems like a great encoding even outside of this project. Predictable length, reasonable density, “double clickable” etc. I’ve been annoyed with both hex and base64 for a while so it’s pretty cool just by itself. > Re: prefix, is the concern that I haven't defined the allowed character se…

My personal favorite encoding is base58 aka Bitcoin address encoding. It uses characters [A-Za-z0-9] except for [0OIl]. It is almost as dense as base64, "double clickable", but not (as) predictable in length as base32. It was chosen to avoid a number of the most annoying ambiguous letter shapes for hand-entry of long address strings. https://en.bitcoin.it/wiki/Base58Check_encoding

Reminds me that Windows activation keys used to exclude a broader set of characters to avoid transcription errors: looking it up again: 0OI1 and 5AELNSUZ

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

#154

Post by veec_cas_tant »

dloreto wrote: post #118
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…

The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.

What value does the checksum provide? I think I'm missing something because I really don't see a benefit.

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

#155

Post by lolinder »

nephanth wrote: post #140
oleganza wrote: post #72

Earlier quoted context omitted.

The problem is not being offended per se, but having your user id accidentally become "user_123fuck567" — that's akin to having a vulgar license plate on your car's forehead. People don't appreciate how lucky they sometimes are.

Are those supposed to be user- facing though?

Using Stripe-style prefixing is most useful if they are—it makes interacting with customer support easier because everyone is on the same page about what this ID identifies.

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

#156

Post by [deleted] »

kibwen wrote: post #64
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 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…

[deleted]

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

#157

Post by hot_gril »

I don't understand putting type names into DB row IDs. You're safest using whatever IDs in your DB make it happiest (usually bigserial in Postgres), and the needs might be pretty specific. Whenever you want to log row IDs, you add whatever context is needed, which will probably include things besides the ID either way. When you want to share an identifier with a customer, you use something entirely different.

The UUIDv7 properties are interesting, but it's worth noting that at least one DBMS really doesn't like the K-sortable property: https://cloud.google.com/spanner/docs/schema-design#uuid_pri...

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

#158

Post by BugsJustFindMe »

Skip the base32 because it's cargo culting and go with a higher base. The premise of crockford's chosen exclusions is fundamentally flawed. In arbitrary fonts, symbol collisions are arbitrary. There are plenty of fonts where any of 5 and S, 2 and Z, V and U, G and 6, 8 and B, and 9 and g are confusable. Likewise vv and w, nn and m.

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

#159

Post by inopinatus »

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 query or cross-reference based on the encoded string instead of the decoded value, then permits hyphens, a leading source of cut-and-paste and line-break errors.

Note that people generally do not type in object identifiers, but they do frequently cut-and-paste them between applications and chat/forum interfaces, forward them by email, search for them in log files. Verbal transmission is rare to non-existent. Under these conditions, pronunciation proves irrelevant, and case-insensitivity becomes an impediment, but consistency and paste/break resilience become necessary.

Base 58 offers a bijective encoding that fits these concerns much more effectively and is more compact to boot. Similarly inspired by Stripe, I've been using type-prefixed base58-encoded UUIDs for object identifiers for some years. user_1BzGURpnHGn6oNru84B3Ri etc.

Edit to add: to be fair to Douglas Crockford, his encoding of base 32 was designed two decades ago, when the usage landscape looked quite different.

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

#160

Post by VanillaCafe »

A pet nit, and the standards probably don't permit this, but for encoding 128-bit numbers, I prefer base-57 in my own implementations. 22 characters for a 128-bit encoding, same as base-64. You can split it into two 11-character 64-bit encodings. You can avoid the two non-alphanumeric characters in base-64 as well as the similar-looking characters like l1 and oO0. And it takes less visible space, so a bit easier for debugging and tabular output with otherwise no loss of generality.
Post reply on HN