I prefer ksuid https://github.com/segmentio/ksuid
Do you mean you prefer ksuid to this new draft? Your comment would be more helpful if you said what about it you prefer.
they have 128 bits of pseudorandom data
Both text and binary representations are lexicographically sortable
They don't have the awkward dash ('-') to mess with url encoding
Can you explain what you mean by that? I have experienced issues with " " as "+" vs. "%20", but dashes... ?
ETA: also, when you put a UUID as text into a lot of search engines, it treats the dashes as token delimiters.
Let's see if I can figure it out (correct me if I'm wrong).
I think maybe these new UUIDs proposed ARE lexigraphicaly sortable (in timestamp order, i think is the implication) in text and binary, these newly proposed UUIDs above? I got the impression that was one of the main things they provide, compared to older UUID formats, one of the main reasons for their proposal? Am I wrong?
I know the new UUIDs look the same as the ones we're used to, where they often have dashes (although there's certainly no requirement you display them with dashes, you can strip the dashes out before putting them in a URL if you want, although yeah it's an extra step).
[If we're talking about URL-encoding we're talking about putting them in URLs? ksuid's 160 bits insead of UUID's 128 , making a longer URL, seems like a downside?]
Not sure how many bits of psuedorandom/entropy they have... Looks like... UUIDv6 has 48 bits of psuedorandom in addition to timestamp, to reduce timestamp collisions. UUIDv7 is variable and can let the application decide (am I understanding right?), but supports up to 62 bits of pseudorandom data. [I guess you prefer a longer ID with more bytes of psuedorandom... just to further minimize possibility of timestamp collission, or other reasons? I am not sure how often existing UUID timestamp collisions happen in practice, anyone know? Anyone ever had one?]
Well, the entire UUID is 128, so obviously not 128 bits of pseudorandom data.
> What about 128 bits of pseudorandom data is preferable to you?
Same as with any hash: collision resistance. That's why we don't use SHA-1 for anything secure any more. The dash problem arises not in the URL but the multipart/form-data encoding, as well as the following:
"when UUIDs are indexed by a search engine, where the dashes will likely be interpreted as token delimiters. The base62 encoding avoids this pitfall and retains the lexicographic ordering properties of the binary encoding."
I have never had or thought of an application where a search engine interpreting the dashes as token delimiters was a problem. But if you have, and it was a problem, ok, that explains your preference I guess!
Curious if anyone reading has run into collisions with existing v1 UUIDs, or knows anyone who has, how often.
Pretty sure these new UUIDs are lexigraphically sortable (in timestamp order) in their hex representation (with or without dashes) as well as binary. Lots of people agree this is important, that in fact seems to be one of the main motivations of these new UUID formats in the draft we're discussing, I think?
They don't have the awkward dash ('-') to mess with url encoding