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

221–230 of 236 posts

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

#221

Post by quelltext »

hot_gril wrote: post #157

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 UUI…

Just think about logging polymorphic object IDs. If you see an identifier with a type you can immediately know what table it is in and you can even build super simple tools like browser extension that let you look up objects by IDs as is. You can also just share these IDs as is with folks on Slack to debug etc. and they know exactly what kind of entities you are talking about.

Super useful and I honestly don't wanna go back to a project that doesn't use this pattern.

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

#223

Post by hot_gril »

quelltext wrote: post #221
hot_gril wrote: post #157

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 UUI…

Just think about logging polymorphic object IDs. If you see an identifier with a type you can immediately know what table it is in and you can even build super simple tools like browser extension that let you look up objects by IDs as is. You can also just share these IDs as is with folks on Slack to debug etc. and they know exactly what kind of entities you are talking about. Super useful and I honestly don't wanna…

Those debug IDs (or URLs, etc) are worth having for the reasons you describe, but it doesn't mean you use those as primary keys in the DB. Something only needs to print them, and debug tools need to understand them.

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

#224

Post by inopinatus »

yencabulator wrote: post #217
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…

Wait, where's the hyphen in Crockford Base32? https://en.wikipedia.org/wiki/Base32#Crockford's_Base32 My favorite base-32 encoding is z-base-32, which I find just gentler on the eyes: https://philzimmermann.com/docs/human-oriented-base-32-encod... The biggest problems with base58 are 1) it works for integers, less so for arbitrary binary data like crypto keys 2) case-sensitivity ISnOtNIcEtOLoOKaT (in my opinion).

The specification of crockford32 is at https://www.crockford.com/base32.html

z-base32 has some nice ideas, although I don’t really give a damn how these things look except where that has functional/ergonomic consequences, since none of them have real aesthetic value. The beauty of numbers is in their structural properties, not their representations. If we really cared about how it feels I’d suggest using an S/KEY-style word mapping instead to get some poetry out of it.

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

#225

Post by yencabulator »

inopinatus wrote: post #224
yencabulator wrote: post #217

Earlier quoted context omitted.

Wait, where's the hyphen in Crockford Base32? https://en.wikipedia.org/wiki/Base32#Crockford's_Base32 My favorite base-32 encoding is z-base-32, which I find just gentler on the eyes: https://philzimmermann.com/docs/human-oriented-base-32-encod... The biggest problems with base58 are 1) it works for integers, less so for arbitrary binary data like crypto keys 2) case-sensitivity ISnOtNIcEtOLoOKaT (in my opinion).

The specification of crockford32 is at https://www.crockford.com/base32.html z-base32 has some nice ideas, although I don’t really give a damn how these things look except where that has functional/ergonomic consequences, since none of them have real aesthetic value. The beauty of numbers is in their structural properties, not their representations. If we really cared about how it feels I’d suggest using an S/KEY-sty…

Ah, "Hyphens (-) can be inserted into symbol strings." If you don't like 'em, don't use 'em.

And the only point of these encodings is to be more human-palatable than base64. If you take that goal out of the equation, just use base64, it's better (denser, more readily supported everywhere). Various base32's and base58 exist because base64 was not human friendly enough.

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

#226

Post by kbumsik »

klabb3 wrote: post #141
dloreto wrote: post #134

Earlier quoted context omitted.

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…

> 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…

What does “double clickable” mean?

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

#228

Post by d0mine »

kbumsik wrote: post #226
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…

What does “double clickable” mean?

Whether "double click" selects the whole id.

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

#229

Post by tomcam »

klabb3 wrote: post #135
tomcam wrote: post #129

Earlier quoted context omitted.

> Add tests goddammit! Hey, you’re pretty smart. How about you add them?

I’m by no means a test police. I’m in fact opposed to a lot of mindless testing for the sake of it. But there are places where unit tests shine, and this is one of them. If you mean that criticism is only allowed if you are willing to commit labor, I disagree with that. I always welcome critique myself - it may be something that I’ve missed. The maintainers always has the last word. As long as there are no hidden exp…

Do you need to be “test police“ to add tests you literally demanded of them?

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

#230

Post by rowbin »

jszymborski wrote: post #23

This is very similar to how I generate IDs in a project I'm working on. Example: |-A-|-|------------B--------------| NMSPC-9TWN1-HR7SV-MTX00-0H8VP-YCCJZ A = Namespace, padded to 5 chars. Max 5 chars. Uppercase. B = Blake3 hashed microtime with a random key. I like how it folds in a time component but that it also doesn't reveal the time it was generated. Here's the snippet: https://gist.github.com/jszym/d3c7907b7b6e9…

Do you generate a random key for each id? If so, you loose the time component of your I'd, because two hashes made at a different time can produce the same hash when using a different key (I think). If you use a single key you need to manage it and keep it secret which isn't really ideal for something simple like id's. If you reveal the key you could as well use an unkeyed hash, right? Maybe a salted hash with the same salt for every key to make dictionary attacks on the creation time harder. But then again it's probably easier to just generate random bits for the id, as you don't have sortability in any case.
Post reply on HN