Comment by jongjong | Hacker News Reader

Comment by jongjong | Hacker News Reader

Parent Full thread

UUIDv7 is not that useful. I'm still using mostly UUIDv4 and UUIDv5.

I'm leaning increasingly heavily on v5 for its determinism which is extremely important for IDs. I would sacrifice every other property to get determinism.

You can't have idempotency without determinism and you can't get reliability without idempotency.

Once you factor in failure and retry scenarios under concurrency, you often need ID determinism. In the rare cases I don't want determinism, I prefer to go all-in on randomness. I prefer my IDs to be well spread out; it scales better, more predictable, less of a security liability (prefer not to have all data clustered in the same place)...

Both UUIDv4 and UUIDv5 outputs are uniformly distributed. IMO this is a desirable property which is well worth a bit of additional compute. v7 feels like an optimization hack, and it comes at a cost.

If you want to get the performance benefits of v7 with the determinism of v5, then you need to have essentially two IDs; the id (v7) and an idempotency key (which is essentially like a second ID you have to maintain; e.g. UUIDv5)... In the end, maintaining a UUIDv7 ID + idempotency key is less performant than just having a single UUIDv5 id which does both jobs for no extra effort... Not to mention, less maintainable and more complicated to use.

> You can't have idempotency without determinism

You absolutely can. The idempotency nonce must be generated by the client who is responsible for firing potential retries. And a random UUIDv4 is a perfectly fine nonce.

If the client _doesn't_ generate a nonce, it doesn't matter what the server side does, they cannot tell from the request data if it's supposed to be a retry or a new request with the same data. A hash such as a UUIDv5 is more performant but not logically any better than comparing the raw data of the two requests. If you use that UUIDv5 as your primary key for insert/update, it's little more than a natural key, with all its well-known drawbacks.

What about if the worker crashes whilst in the middle of copying over some rows from a number of large Excel spreadsheets? Then when you restart, you need a way to derive the ID from file name + tab name + unique row identifier (for example) because your v4 UUID which you used to identify each row would have been lost in the crash... Generating a v4 UUID for each row can cause duplicates in such scenarios. If your ID for each row is deterministic and chosen based on data which uniquely identifies each row, you don't have this problem.

In some cases, you can solve the problem by clearing rows based on timestamps or tracking the last copied input row but these are often unreliable. There's usually a bit of overlapping data left over from a previous run which you have to re-process and for those you want the IDs to clash.

> What about if the worker crashes whilst in the middle of copying over some rows from a number of large Excel spreadsheets?

You don't need a nonce at all in this case.

The purposes of nonces is to make non-idempotent requests into idempotent ones.

"Write 'lol' in sheet 1, row 5, column B" is already idempotent.

Hey author here, thanks for reading the post. I haven't seen UUIDv5 used very often but I'll have to think about the idempotency angle more.

One thing that concerns me is that UUIDv5 is based on SHA1, which is an insecure hashing algorithm. I generated a pair of colliding UUIDv5s in an earlier post in this series (https://alexsci.com/blog/uuid-oops/#insecure-hash-functions). So I don't think you can use UUIDv5 for security critical functions.

Interesting! That said, these examples appear to be crafted in a special way to cause the collision. In a practical scenario with normal usage, I suspect it would be essentially impossible. Sure, it can be a problem in some niche scenarios with a determined attacker but a collision would just mean that the user is not able to create the resource (the system would falsely indicate that the resource already exists); but that's not too bad. At worst, it would reveal the existence of a resource with a specific UUID, but could the attacker have achieved the collision if they didn't know the target UUID already? It doesn't seem like a viable attack given how little information it gives you.

Correct, this is a very specific attack where an attacker can generate UUIDv5 collisions but cannot force a collision of a chosen UUID. If your usage doesn't serve any security functions then its fine to use an insecure hash function.

One thing I find interesting is that we seem to be at the end of the road for secure hash-based UUIDs. SHA-1 was already truncated (I.E. weakened) from 160 bits to 122 bits to fit the UUID width. To fit a SHA-256 hash you'd need to throw away a majority of the bits!

Reply on news.ycombinator.com