UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases. The only requirement is that the variant and version bits MUST be set as defined in Section 4.1 and Section 4.2. UUIDv8's uniqueness will be implementation-specific and MUST NOT be assumed.The only explicitly defined bits are those of the version and variant fields, leaving 122 bits for implementation specific UUIDs. To be clear: UUIDv8 is not a replacement for UUIDv4 Section 5.4 where all 122 extra bits are filled with random data.Some example situations in which UUIDv8 usage could occur: An implementation would like to embed extra information within the UUID other than what is defined in this document. An implementation has other application/language restrictions which inhibit the use of one of the current UUIDs.
0 10 20 30 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | year-month-day | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hour:minute | ver | rand | seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |var| milliseconds | rand | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rand | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We are using https://github.com/hayageek/uuid-v8 to generate UUID V8.
The global computing community has been significantly benefitted by the Universal Unique Identifier (UUID), particularly in data management. A UUID, characterized by 32 hexadecimal digits, renders a theoretically collision-free namespace for various applications and systems. As technologies evolve, the need for more innovative UUID versions crystallizes. Here, we explore UUID Version 8, a proposed new format whose draft is very well explained in this link.
The previous UUID versions up to Ver. 5 have distinctive attributes tailored for distinct use-cases. For instance, version 4 utilizes random numbers, version 1 is time-based incorporating an identifier for generating the UUID, and versions 3 and 5 adopt hashing mechanisms for namespaces and name strings. As the need for UUIDs heightens, these versions seem increasingly inadequate for more complex tasks; a fact that has driven the need for UUID Version 8.
UUID Version 8's formation stems from the need for a UUID that can manifest many variations and use-cases, offering a measure of flexibility that's missing in previous versions. The most crucial element of UUID Version 8 is its deliberate flexibility, built to handle more complex and specific tasks and applications that typical UUID versions cannot efficiently accomplish. With this flexibility, Version 8 helps in increasing operational efficiency by allowing users to represent any data they want in the way they want.
An interesting aspect of the Version 8 UUID is its ability to house various other UUID versions. It's designed to contain related information about the original UUID from which it was derived, helping in building regular UUIDs and producing an output that unifies prior UUID versions and payloads in a single ID.
With the swift evolution of digital technology, the simple UUID versions can no longer keep pace. UUID Version 8 is a fitting response, providing the flexibility and usability not readily available in prior UUID versions. Once fully implemented, version 8 could potentially revolutionize how we deal with UUIDs by offering unique flexibility and compatibility. You can follow the draft for more detailed information.