Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye integers, hello UUIDv7

buildkite.com

Post reply on HN
Print view View original

151–160 of 376 posts

Re: Goodbye integers, hello UUIDv7

#151

Post by zo1 »

afavour wrote: post #42
andersa wrote: post #27

Earlier quoted context omitted.

There are definitely many cases where it isn't an issue since you were going to tell the user the time anyway (like sent time on a message)

Can’t agree with that logic. Unless it’s specifically documented leaking timestamp data is going to get totally forgotten. So when you add (e.g.) the ability to change the sent timestamp on a message you’re going to inadvertently leak when a timestamp has been changed. Could cause embarrassment in a lot of scenarios.

This reminds me of that recent investigation regarding fudged data in those Harvard studies. The fields stored the "original" ID, solidifying their creation sequence, which differed to the displayed sequence - Implying that the fields were updated out-of-sequence, thereby they were tampered with.

Re: Goodbye integers, hello UUIDv7

#152

Post by bajsejohannes »

matja wrote: post #144
bajsejohannes wrote: post #123

Earlier quoted context omitted.

I'm actually working on encrypting database keys like this, and I opted for a string ID with "url safe" base64. It avoids the ambiguity of looking like a UUID when it's not, and I prefer "o3Ru98R3Qw-_x2MdiEEdSQ" in a URL over "a3746ef7-c477-430f-bfc7-631d88411d49". (Not that either one is very beautiful)

Curious on the preference there, especially when characters in base64url encoding can look similar/ambiguous in some fonts.

The preference is purely about the amount of characters. I hope no one will ever actually read or write these URLs, but you never know...

Re: Goodbye integers, hello UUIDv7

#153

Post by t0mas88 »

CSDude wrote: post #105
tgv wrote: post #70

Earlier quoted context omitted.

The German tank production capacity was estimated by serial numbers of captured tanks. There are ways to read all kinds of information by observing energy usage. High resolution time and sequence data undoubtedly reveal more than you’d like.

Most of our lives as boring SaaS etc. software developer will not be near as exciting as this, but of course you may never know. I parsed the EV chargers APIs where I live (using Frida in Android) and one of the fields returned the daily revenue and profit.

Could be quite useful information to competing charger networks or in future M&A discussions.

I've seen a project for a trading firm that inferred all kinds of traffic and revenue numbers for companies before their quarterly earnings were made public. It wasn't perfect, but knowing with a certain confidence level whether the numbers were going to be better or worse than estimate was profitable for them.

Re: Goodbye integers, hello UUIDv7

#154

Post by danwee »

So, how do you guys use UUIDs for real? I worked in a company in which they were using UUIDs in Mongo, and of the most painful things were implementing API endpoints that filter resources. Imagine you have an endpoint in which you are filtering by resources A, B, C and D. Ideally you would end up with something like this:

    GET /filter?a_id=X&b_id=Y&c_id=Z&d_id=w
But in practice we were using POST and passing the ids in the body payload. Why Because my old team said "the UUIDs are long, so we may reach the maximum URL length if we pass them as parameters". I didn't like it, and I still don't like it at all.

Re: Goodbye integers, hello UUIDv7

#155

Post by oconnore »

lysium wrote: post #87
oconnore wrote: post #55

Earlier quoted context omitted.

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

Neat idea. I’m afraid you won’t be able to ever rotate that key, would you? Since it’s result is externally used as an identifier, you would have to rotate the external identifiers, too.

I think you could but it would further complicate the id scheme (would need some sort of a version mask to facilitate a rotation window).

Re: Goodbye integers, hello UUIDv7

#156

Post by groestl »

kijin wrote: post #63
jiggawatts wrote: post #38

It seems insane to me to “validate” GUIDs/UUIDs. Half the point of these things is that they’re treated as opaque identifiers.

If UUIDv4 was all that ever existed, there would be no need to validate anything apart of the fact that it's supposed to contain 32 hexadecimal characters. All other versions, including the new v7, attach meaning to certain bits of the identifier. That cat has been out of the bag for a long time, so now everyone needs to maintain code to ensure that some rogue node doesn't spew back-dated identifiers belonging to the…

UUIDv4 also contains some bits with meaning. But joke's on them, I tend to even randomize the version bits and call it UUIDv0.

Re: Goodbye integers, hello UUIDv7

#157

Post by dgb23 »

danwee wrote: post #154

So, how do you guys use UUIDs for real? I worked in a company in which they were using UUIDs in Mongo, and of the most painful things were implementing API endpoints that filter resources. Imagine you have an endpoint in which you are filtering by resources A, B, C and D. Ideally you would end up with something like this: GET /filter?a_id=X&b_id=Y&c_id=Z&d_id=w But in practice we were using POST and passing the ids i…

The maximum url length is typically quite long.

Another thing is that you don’t necessarily need to encode uuids canonically. They are just u128’s. It’s relatively straightforward to find a url friendly string representation that is shorter.

Re: Goodbye integers, hello UUIDv7

#158

Post by matharmin »

BiteCode_dev wrote: post #100
imiric wrote: post #97

Earlier quoted context omitted.

I'm a fan of Cuid2[1] for this reason. They are compact, don't leak information, and make a good case why k-sortable IDs are unnecessary, or even harmful for performance. I'm using sequential integers and created_at/updated_at timestamps for internal use, and Cuid2 IDs externally. [1]: https://github.com/paralleldrive/cuid2

What benefice over uuid4 ?

Reading their docs: No real benefits, just misconceptions.

1. Collision resistance / "weak" PRGNs used to generate UUIDv4. Firstly, these are properties of the implementation, not the spec. Secondly, the source for calling the browser `Crypto.getRandomValues()` insecure is an issue that has been fixed back in 2016. I would not trust the developers of this implementation to do a better job than current browsers.

2. "Not URL or name friendly": Fair, but not very strong argument.

3. "Horizontally scalable" and "offline-capable": No argument given for why UUIDv4 does not meet these requirements, apart from point 1 above.

4. "Too fast": No argument given for why having a slower algorithm to generate random ids is more secure. Both UUIDv4 and Cuid2 use a similar number of random bits (122-124). When using a secure PRNG, both are equally difficult to guess, the SHA3 hashing doesn't add anything. You don't have to try and guess the "input" of the Cuid2 - you can just try to guess the "output" and skip the SHA3 hashing. It would be impossible to actually guess a generated ID, but UUIDv4 is just as impossible. Also no argument given for why UUIDv7 is fine but UUIDv4 is not.

I've used UUIDv4 for genering unique IDs for over 10 years now. I have run into collisions, when I hand-rolled my own implementation for J2ME with major bugs many years ago - ended up with around 20 bits of entropy instead of 122. That's not a reason to not use UUIDv4, just a reason to not implement it yourself unless you really know what you're doing.

Re: Goodbye integers, hello UUIDv7

#159

Post by danwee »

dgb23 wrote: post #157
danwee wrote: post #154

So, how do you guys use UUIDs for real? I worked in a company in which they were using UUIDs in Mongo, and of the most painful things were implementing API endpoints that filter resources. Imagine you have an endpoint in which you are filtering by resources A, B, C and D. Ideally you would end up with something like this: GET /filter?a_id=X&b_id=Y&c_id=Z&d_id=w But in practice we were using POST and passing the ids i…

The maximum url length is typically quite long. Another thing is that you don’t necessarily need to encode uuids canonically. They are just u128’s. It’s relatively straightforward to find a url friendly string representation that is shorter.

> It’s relatively straightforward to find a url friendly string representation that is shorter.

Are we talking about shortening the whole URL or shortening specific UUIDs? If the latter then I imagine one would still need to keep track of the mapping UUID shorten version, somewhere, right? If so, why not just add yet another field/column for an old good numeric integer that can be used for filtering? Would that work?

Re: Goodbye integers, hello UUIDv7

#160

Post by wvh »

A few years back, I wrote some code that generates a sortable 128-bit UUID-like identifier starting with a milliseconds-since-epoch timestamp, a node number and a random byte tail. It has been working fine in Postgresql, using its builtin UUID type. I suppose downstream system have been using the string representation though. The main reason for going such an identifier was being able to generate them from different, non-centralised places. A nice side effect is that you can't accidentally get an erroneous ID that happens to work the way you can with a sequential integer primary key.

For another project, I've also used sortable 64-bit snowflake-like identifiers; they have the added benefit of being able to use 64-bit integer representation in code and database identifiers, even if you might want to externally represent them in base58 or similar encoding.

The original UUID types aren't as useful as they once were, so it'd be worth writing a new RFC and extending those original types.

Post reply on HN