Re: UUID version 6 proposal, initial feedback

[Brad Peabody <bradgareth@xxxxxxxxx>]

I get where you're coming coming.  The issue is there are common use cases where just using cryptographic nonce does not work well.

Random UUIDs as primary keys in databases have bad write amplification properties.  (example: https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079)  A timestamp provides locality in database indexes as well as a useful natural order in the database.

The text format of a UUID is generally not the best way to store it in memory.  So after an identifier (timestamp or not) has been created there is the issue of how you show it to humans vs its binary form, and there are tradeoffs with different formats (size, case-insensitivity, backward compatibility).

What I laid out is essentially a collection of options that seem to come up time and again dealing with unique identifiers.  I think there is benefit in standardizing it.  The list of open source projects that each have their own way of creating unique identifiers is quite long and the wheel is reinvented often.  (Some examples: https://github.com/segmentio/ksuid https://github.com/rs/xid https://github.com/kjk/betterguid https://github.com/sony/sonyflake https://github.com/oklog/ulid https://github.com/chilts/sid )

I agree this is not a terribly complex problem and some applications can just read from /dev/urandom and be done with it.  But I also believe the above concerns are real and affect a lot of real-world applications.

On 1/31/20 1:45 PM, Salz, Rich wrote:

I don’t understand the purpose of all that mechanism.  UUID’s are supposed to be opaque identifiers; if you intend folks to look inside them, then you should not be using UUID, you should be using something else where the insides are on the outside, as it were.

 

UUID’s are very old, they were first part of Apollo’s Network Computing Architecture in the 1980’s.  If we were recreating them today, we’d just use a cryptographic nonce.  I suggest that’s what you do as well.