Support new IETF UUID formats
dncnkrs opened this issue · 17 comments
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
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.)
The new UUID formats are being discussed in this github repo: https://github.com/uuid6/uuid6-ietf-draft
I've just created an isomorphic implementation for the current UUIDv7 draft: https://github.com/kripod/uuidv7 – I would appreciate some feedback about it.
@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.
@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.
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.
Marking as stale due to 90 days with no activity.
Closing issue due to 30 days since being marked as stale.
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.
Tracking support for RFC4122bis here: https://github.com/orgs/uuidjs/projects/1
Marking as stale due to 90 days with no activity.
I just came across this article, and I'd really like to start using UUIDv7.
It looks like the code in csmith23#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: #681
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