Support new IETF UUID formats

[dncnkrs]

A recently published draft RFC proposes three new time-based UUID formats. The UUIDv1 is also time-based, but the timestamp is formatted little-endian, whereas the new formats use a big-endian format. This means the UUID's will naturally sort in order of time, which has several engineering advantages.

Because the RFC is still a draft, I wouldn't yet expect that UUID libraries can generate the new formats. I'd like to know if this library intends to implement them, however.

I thought it would be useful to create this issue, so we can see if:

• the new formats will be implemented in this library,
• if so, the status of the implementation (assumed to be after the RFC is published).

https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-01

[broofa]

Good issue. I'm generally in favor of this, as the new versions have some much-needed improvements over the original spec. However, this spec appears to still be an early, unadopted draft (e.g. numerous typos, not yet assigned an RFC #).

Until this is more formally adopted by the IETF, I don't think it's appropriate for us to officially support it. (That's not to say we couldn't publish an "experimental" branch / release, but I don't see that as a high priority task.)

[fabiolimace]

The new UUID formats are being discussed in this github repo: https://github.com/uuid6/uuid6-ietf-draft

[kripod]

I've just created an isomorphic implementation for the current UUIDv7 draft: https://github.com/kripod/uuidv7 – I would appreciate some feedback about it.

[CMCDragonkai]

@kripod in your example how does one provide the node id in a distributed context?

Also I was wondering if we can provide a custom clock source. In case we wanted a monotonic clock.

[kripod]

@CMCDragonkai providing a custom machine ID isn’t possible yet, but 62 random bits should be sufficient to avoid collisions. Does the spec draft mention how to use machine IDs within a UUIDv7?

Not sure if a custom clock source may ever be provided, as JS is single-threaded and thus, seq is guaranteed to be monotonic.

Please open new issues about these over here.

[CMCDragonkai]

Done:

• https://github.com/kripod/uuidv7/issues/1
• https://github.com/kripod/uuidv7/issues/2

[CMCDragonkai]

Based on @kripod work and some discussions in the upstream spec and the prototype code here https://github.com/uuid6/prototypes, we've developed js-id https://github.com/MatrixAI/js-id for use in our company's projects. The IdSortable (https://github.com/MatrixAI/js-id/blob/master/src/IdSortable.ts) there implements UUIDv7 millisecond resolution based on the latest revision of the spec and resolves my 2 issues that I posted above in https://github.com/kripod/uuidv7.

[github-actions[bot]]

Marking as stale due to 90 days with no activity.

[github-actions[bot]]

Closing issue due to 30 days since being marked as stale.

[broofa]

Quick update: The new versions are being spec'ed out by the UUID revision Working Group based on the draft work mentioned previously.

There doesn't seem to be a lot of concern or contention so far, which has me thinking we could start add support for these new formats... maybe under an "experimental" release version of some sort without too much risk of major changes being needed.

[broofa]

Tracking support for RFC4122bis here: https://github.com/orgs/uuidjs/projects/1

[github-actions[bot]]

Marking as stale due to 90 days with no activity.

[DevBrent]

I just came across this article, and I'd really like to start using UUIDv7.

It looks like the code in https://github.com/csmith23/uuid/pull/1 was solid (please someone more qualified audit the generator, but the test coverage and updates to documentation looked great) but I don't see a PR into this repo.

Edit: I now found the discussion continued in: https://github.com/uuidjs/uuid/pull/681

[Crsk]

If I'm going to start a new project, is it a bad idea to use v1 only temporarily while waiting for v7 experimental or not? so that I structure my identifiers as Postgres uuid and have lexicographic sorting

[notramo]

@Crsk I think, trying to hurry up the implementation doesn't add to the conversation. You can already use UUID v7 in your project, as there are other JS implementations of UUID v7: https://github.com/LiosK/uuidv7 (more features, slightly bigger bundle size) https://github.com/kripod/uuidv7 (minimalistic, small bundle size)

Also, there are multiple Postgres add-ons: https://github.com/craigpastro/pg_uuidv7 (Rust) https://github.com/fboulnois/pg_uuidv7 (C)

[fabiolimace]

You all probably already know, but just in case, RFC 9562 was published a few days ago (May 7, 2024).

https://www.rfc-editor.org/rfc/rfc9562 https://datatracker.ietf.org/doc/rfc9562

[broofa]

Now tracking this in #749