Nice presentation. I've always been skeptical of the value of UUIDs. It's very easy to make a unique string. Formatting it in a particular way, however, serves no real purpose and it might not be necessary for your use case. UUIDs (aside from v4) also have some nasty properties. For instance, revealing a MAC address is now considered problematic. As is exposing the output of a clock, which has been used in interesting ways to undermine privacy (clock skew can be used for de-anonymisation, even for determining CPU load). Counters and timers also allow an observer to correlate the creation of different identifiers. Why not make a string with the properties you desire? You might need more than 120 bits to achieve all that, but that's just another reason not to use UUIDs. A library that provided these functions (maybe while addressing the above concerns), would be a valuable addition. On Wed, Jul 4, 2018 at 10:42 AM Brad Peabody <bradgareth@xxxxxxxxx> wrote: > > I would like to get some initial feedback, and suggested next steps, on the idea of making an RFC that covers a version 6 for UUIDs. It would have an embedded timestamp and sorting by its raw bytes results in a sequence equivalent to sorting by time. This is not addressed by existing UUID types. (The closest one is version 1, but due to the byte encoding it does not sort correctly.) > > There is also seems to be some ambiguity in the existing RFC on when to increment the counter field which I think can be clarified. > > I did a prototype implementation and basic write-up on the details here: https://bradleypeabody.github.io/uuidv6/ > > I’m also thinking of covering the base64 encoding form which retains the sorting properties but makes it human readable and is significantly shorter than the long hex encoded form. > > Having these things is very useful when considering UUIDs as database primary keys, which is becoming more and more common in distributed systems; and indeed this is the main motivation. > > Any help or advice on moving forward with this would be appreciated. > > - Brad >
