3 ms·
I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.
by pclmulqdq 8mo ago
I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.
- 8organicbits 8mo agoNo, UUIDv8 offers 122 bits for vendor specific or experimental use cases. If you fill those bits randomly, you get the same amount of randomness as a v4. The spec is explicit that it does not replace v4 for random data use case. > To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data. https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2 https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2
- pclmulqdq 8mo agoYes, vendor-specific data can be 100% random.
- 8organicbits 8mo agoIt can be, but you should prefer UUIDv4 if you do that. One problem is that UUIDv8 does not promise uniqueness. > UUIDv8's uniqueness will be implementation specific and MUST NOT be assumed. Here's a spec compliant UUIDv8 implementation I made that doesn't produce unique IDs: https://github.com/robalexdev/uuidv8-xkcd-221 https://github.com/robalexdev/uuidv8-xkcd-221 So, given a spec-compliant UUIDv4 you can assume it is unique, but you'd need out-of-band information to make the same assumption about a UUIDv8. I wrote much more in a blog post: https://alexsci.com/blog/uuid-oops/ https://alexsci.com/blog/uuid-oops/