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

231–236 of 236 posts

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

#231

Post by [deleted] »

yencabulator wrote: post #225
inopinatus wrote: post #224

Earlier quoted context omitted.

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.

[deleted]

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

#232

Post by hot_gril »

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 only worthwhile UUID standard IMO is v4 (simple random), and I still don't get why it needs dashes. The other ones don't really accomplish anything.

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

#233

Post by hot_gril »

dap wrote: post #174

It's weird to me that people talk about UUIDv4 as bad for databases because of locality. This behavior can be good or bad, depending on what you're doing. Sure, UUIDv4 is worse if you're using it to locate a bunch of related objects that you want to be on the same database node. (If you're doing that, though, you can often attach some kind of group identifier -- e.g., "user" -- and index that.) I generally prefer UUI…

Yep. Spanner docs even tell you not to use time-ordered keys.

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

#234

Post by diroussel »

veec_cas_tant wrote: post #154
dloreto wrote: post #118

Earlier quoted context omitted.

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.

The benefit is that you can reject bad requests to an API more easily.

For one application I used a base 58 encoded value. Part of it was a truncated hmac, which I used like check digits. This meant I could validate IDs before hitting the DB. As an attacker or script kiddie could otherwise try a resource exhaustion attack.

So in the age of public internet faceing APIs and app urls, I think built in optional check digit support is a good idea.

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

#235

Post by veec_cas_tant »

diroussel wrote: post #234
veec_cas_tant wrote: post #154

Earlier quoted context omitted.

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

The benefit is that you can reject bad requests to an API more easily. For one application I used a base 58 encoded value. Part of it was a truncated hmac, which I used like check digits. This meant I could validate IDs before hitting the DB. As an attacker or script kiddie could otherwise try a resource exhaustion attack. So in the age of public internet faceing APIs and app urls, I think built in optional check dig…

I struggle to see how 10 bits of check data will help much. I guess if the extra bits aren’t persisted to storage it doesn’t hurt so why not?

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

#236

Post by diroussel »

veec_cas_tant wrote: post #235
diroussel wrote: post #234

Earlier quoted context omitted.

The benefit is that you can reject bad requests to an API more easily. For one application I used a base 58 encoded value. Part of it was a truncated hmac, which I used like check digits. This meant I could validate IDs before hitting the DB. As an attacker or script kiddie could otherwise try a resource exhaustion attack. So in the age of public internet faceing APIs and app urls, I think built in optional check dig…

I struggle to see how 10 bits of check data will help much. I guess if the extra bits aren’t persisted to storage it doesn’t hurt so why not?

Storage can get corrupted, columns can be truncated. For the applications I tend to touch correctness and the ability to detect errors and tamper are more important that a couple of bytes per row. But every application and domain is different.
Post reply on HN