Proposal: `randomUUIDv7()`

[htunnicliff]

I'd like to propose that the working group consider adopting randomUUIDv7() as a counterpart to the existing randomUUID() function.

v7 UUIDs have been growing in popularity over the last several years and have received implementations in an increasing number of notable projects:

• Node.js - crypto: implement randomUUIDv7() nodejs/node#62553
• Deno - feat(uuid): stabilize uuidv7 module denoland/std#6897
• Bun - node:crypto: sync the crypto suite to Node v26.3.0 and fix surfaced gaps oven-sh/bun#32623

Given the wide precedence and usage of the existing randomUUID() function, I think adopting a v7 counterpart would be of worthwhile consideration.

[lino-levan]

Would be cool! Was important enough for me to take time off of work to stabilize the Deno standard library implementation.

[annevk]

The way it's defined at https://www.rfc-editor.org/info/rfc9562/#section-5.7 does not seem suitable for the web platform. We don't want implementation-defined behavior.

[htunnicliff]

The way it's defined at https://www.rfc-editor.org/info/rfc9562/#section-5.7 does not seem suitable for the web platform. We don't want implementation-defined behavior.

Unless I'm misreading that RFC, it seems to be the standards document for UUIDs as a whole.

Did the original randomUUID() function rely on any standards documents?

[annevk]

Of course, see https://w3c.github.io/webcrypto/#Crypto-method-randomUUID

[htunnicliff]

I see – thank you for linking!

It appears that the original RFC 4211 used for the randomUUID() implementation has been obsoleted by RFC 9562.

The way it's defined at https://www.rfc-editor.org/info/rfc9562/#section-5.7 does not seem suitable for the web platform. We don't want implementation-defined behavior.

Does this remark mean that you don't believe UUIDv7 is worth implementing? Or are you still open to UUIDv7 but don't want to use the behavior as it is depicted in the new RFC? Or something else?