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

RFC 9562: Universally Unique IDentifiers (May 2024)

rfc-editor.org

Post reply on HN
Print view View original

11–20 of 48 posts

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#11

Post by posting_mess »

sedatk wrote: post #9
posting_mess wrote: post #3

[flagged]

> but we cant come up with a decent UUID scheme maybe because we can’t come up with an unambiguous definition of “decent.”

We do and we dont frequently agree on whats "decent".

Most routers implement a set of security standards/protocols for VPN's that are "decent" and make the play nicely with each other.

The "Redis protocol" gets re-implemented frequently because its "decent" and useful to many vendors.

I cant speak for "encryption" but there has to be numerous implementations of various algorithms.

And this is true for many other protocols.

UUID seems mathematically "provable" or "verifiable", why are we wasting time on needless "wrong" / "non decent" implementations?

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#13

Post by deathanatos »

> Some UUID implementations, such as those found in Python and Microsoft, will output UUID with the string format, including dashes, enclosed in curly braces.

No … Python doesn't emit them enclosed in curly braces?

  >>> str(uuid.uuid4())
  '593a2ffb-eafc-484a-9a90-93bc91805651'

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#14

Post by LegionMammal978 »

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded.

That seems like a rather vague way of addressing leap seconds for UUIDv7. For positive leap seconds, an 'exclusion' of that second would suggest that the millisecond counter is halted until the leap second is over, which doesn't seem ideal for monotonicity. And an 'exclusion' of a negative leap second hardly makes any conventional sense at all, with regard to the millisecond counter.

Contrast with the timestamp of UUIDv1/v6, where positive leap seconds can just be handled by incrementing the clock sequence.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#17

Post by WorldMaker »

ComplexSystems wrote: post #4

Surprising we're using 128 bits - some back of the napkin math tells me that may not be enough to avoid collisions...

For hash functions, maybe not anymore, given the birthday paradox/pigeon-hole principle and other math problems in bucketing inputs versus the attack patterns for breaking hash functions and causing intentional collisions. For mostly purely random entropy in uses like UUID (and IPv6) the classic answer is that it is still more overall space than "atoms in the visible universe".

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#18

Post by anamexis »

LegionMammal978 wrote: post #14

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. That seems like a rather vague way of addressing leap seconds for UUIDv7. For positive leap seconds, an 'exclusion' of that second would suggest that the millisecond counter is halted until the leap second is over,…

There will not be any leap seconds after 2035, and very likely there will never be any negative leap seconds.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#19

Post by Spivak »

ComplexSystems wrote: post #4

Surprising we're using 128 bits - some back of the napkin math tells me that may not be enough to avoid collisions...

Depends on your problem domain. You can be Twitter/Discord sized and get away with 64 bits. When you start dedicating parts of your UUID to a timestamp the possibility of collisions does go way up since now a significant chunk of the UUID will be the same for everyone. But when you deploy this variant you aren't trying to make globally unique ids anymore, you're trying to make application unique ids. You are sill very unlikely to not also have a globally unique id because 128 bits gives a lot of room to play around.
Post reply on HN