Analyzing New Unique Identifier Formats (UUIDv6, UUIDv7, and UUIDv8)

I am a big fan of the new uuid v7 format.<p>It has the advantage of being a drop in replacement most places everyone uses v4 today. It also has the advantage over other specs of ulid in that it can be parsed easily even in languages and databases with no libraries because you just need some obvious substr replace and from_hex to extract the timestamp. Other specs typically used some custom lexically sortable base64 or something that always needed a library.<p>Early drafts of the spec included a few bits to increment if there were local ids generated in the same millisecond for sequencing. This was a good fit for lots of use cases like using the new ids for events generated in normal client apps. Even though it didn’t make the final spec I think it worth implementing as it doesn’t break compatibility

I have recently wondered why Ruby on Rails is using a full-length SHA256 for their ETag fingerprinting (64 characters) when a UUID at 36 chars would probably be entirely enough to prevent collisions and be more readable at the same time. Esbuild on the other hand seems to use just 32bit (8 chars) for their content hash.

I don’t understand the part where monotonicity of UUIDs is discussed. UUIDs should never be assumed monotonic, or in a specific format per se. If you strictly need monotonicity, just use an integer counter. Let UUIDs be black boxes, and assume that v7 is just a better black box that deals with DB indexes better.

For v7, the last chunk of bits (rand_b) can be &quot;pseudorandom OR serial&quot;. There is no flag bit that must indicate which approach was used.<p>Therefore, given a compliant UUIDv7 sample, it is impossible to interpret those bits. You can&#x27;t say if they are random or serial without knowing the implementation, or stochastic analysis of consecutive samples. It&#x27;s a black box.<p>The standard would be improved if it just said those bits MUST be uniquely generated for a particular timestamp (e.g. with PRNG or atomic counter).<p>Logically, that&#x27;s what it already means, and it opens up interesting v8-style application-specific usages of those bits (like encoding type metadata in a small subset, leaving the rest random), while also complying with the otherwise excellent v7 standard.

v7 is really helpful for meaningful UX improvements.<p>ex. I&#x27;m loading your documents on startup.<p>Eventually, we&#x27;re going to display them as a list on your home screen, newest to oldest.<p>Now, instead of having to parse the entire document to get the modified date, or wait for the file system, I can just sort by the UUID v7 thats in the filename.<p>Is it perfect? No, ex. we could have a really old doc thats the most recently modified, and the doc ID is a proxy for the <i>creation</i> date.<p>But its <i>much</i> better than the status quo of &quot;we&#x27;re parsing 1000+ docs at ~random at startup, please wait 5 seconds for the list to stop updating over and over.&quot;

I&#x27;m having trouble understanding the use of v8. It can be pretty much any bits as long as it has 1000 in the right spot? It strikes me as too minimal to be useful. I must be missing something