Hacker News Reader

Comment by ivan_gammel | Hacker News Reader

The strategy "internal int-external uuid" can be simplified if you use encryption and hypermedia API. It's possible to encrypt int and some additional information and format it as uuid v4 (random). For external users that know natural keys of some objects it's possible then to discover the rest of objects by navigation via API, where UUIDs are just some pseudo-random parts of the URIs.

View on HN

I was wondering a similar implementation. I encrypt/decrypt database IDs to opaque them on the API. For primary entities but not enums/etc. I separated API vs Core/Database so I wasn't too fond of adapting the entities to add a sort-of public id column so I create it at run-time.

I can share my code on Github, it will be interesting to find some commons. Probably, this approach deserves more attention.

Why would you format it as a UUIDv4 instead of just leaving all bits intact?

Well, that's possible, but I'd say it's generally better to keep close to the spec and v4 is the closest option here.

But what's the value in the "spec" here? I see people mentioning this and I'm wondering what the rationale is.

The rationale is that you can use them along with those other versions of UUID that contain nonrandom data.

Assume Bob uses one such not-entirely-random UUID variety and actually makes use of the embedded information. Charlie uses random UUID. Bob and Charlie merge their data.

If Charlie had filled the version bits with random garbage, the merge would poison Bob's use of the embedded information.

Basically, UUIDs are a discriminated union type.

Thanks, that's the best answer.

By violating the spec you're assuming you'll never want to use a tool that strictly adheres to the spec. Postel's Law works best because it accommodates some people not following it.

To take advantage of native UUID support in a database, e.g. PostgreSQL stores them in 128 bits. Also every UUID carries version number so minimal formating needs to be performed to comply with the standard.

So you're saying Postgres actually wastes cycles verifying the version information and doesn't treat UUID just as a 16 byte opaque structure?

Well, there's the "input format" (or rather two), which gets parsed into the internal representation. The input format can be either hex text, which allows dashes in some positions, or binary, in which it's just a bytearray. There's no verification otherwise, unless you treat generation of UUIDs, which allows to specify the type, as such.

Second point: Verifying version information would hardly matter cyclewise.

I'm not sure what you mean exactly. The textual representation of an UUID HAS all the bits intact. UUID formatting is not lossy compression.

UUID v4 "spec" leaves 122 bits for randomness and has 6 fixed bits for "version" information. I'm suggesting that following the spec on such stuff is a total waste and serves no point, and you're better off with a random 128-bit number.

Well, then it's not an UUID. It's just 128 random bits. If you just want to be the most random possible, you can go 256, 512, 1024, etc. That may be what you want, but you can't say UUID v4 is a "total waste" or "serves no point".

It's purpose is to never collide with another UUID v4, not to be the most unique value ever.

UUIDv4 is a 122 bit random number. Having another 6 random bits won't make them collide.

Also if there's UUIDs in your system colliding with a 128 bit random numbers then the rng is broken or your UUID generator would be great to crack encryption keys.

Reply on news.ycombinator.com