3 ms·

The IETF draft mentions ksuid in the "prior art consulted" section. Do you mean you prefer ksuid to this new draft? Your comment would be more helpful if you s

The IETF draft mentions ksuid in the "prior art consulted" section. Do you mean you prefer ksuid to this new draft? Your comment would be more helpful if you said what about it you prefer.

cratermoon 5y ago
I prefer ksuids because 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
- leo_bloom 5y ago
  > 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... ?
  - cratermoon 5y ago
    Not in URLs per se, but in HTML URL Encoded Multipart Forms, i.e. enctype="multipart/form-data" ETA: also, when you put a UUID as text into a lot of search engines, it treats the dashes as token delimiters.
- jrochkind1 5y ago
  Which of those things are not true of these new UUID formats proposed? 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?]
  - cratermoon 5y ago
    > Which of those things are not true of these new UUID formats proposed? 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." https://segment.com/blog/a-brief-history-of-the-uuid/ https://segment.com/blog/a-brief-history-of-the-uuid/
    - jrochkind1 5y ago
      OK, thanks for explaining! 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?
      - cratermoon 5y ago
        Yeah, they've solved one issue with the UUID format by giving them k-sortability, but the other issues are still there. Ultimately, if you need some kind of UUID-compatible representation (eg for Vertica UUID columns), then these are good approaches. If you need to solve the same problems but don't have a reason to be locked into UUIDs, pick something else.

The IETF draft mentions ksuid in the "prior art consulted" section. Do you mean you prefer ksuid to this new draft? Your comment would be more helpful if you said what about it you prefer.

cratermoon 5y ago

I prefer ksuids because 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

leo_bloom 5y ago
> 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... ?
- cratermoon 5y ago
  Not in URLs per se, but in HTML URL Encoded Multipart Forms, i.e. enctype="multipart/form-data" ETA: also, when you put a UUID as text into a lot of search engines, it treats the dashes as token delimiters.
jrochkind1 5y ago
Which of those things are not true of these new UUID formats proposed? 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?]
- cratermoon 5y ago
  > Which of those things are not true of these new UUID formats proposed? 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." https://segment.com/blog/a-brief-history-of-the-uuid/ https://segment.com/blog/a-brief-history-of-the-uuid/
  - jrochkind1 5y ago
    OK, thanks for explaining! 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?
    - cratermoon 5y ago
      Yeah, they've solved one issue with the UUID format by giving them k-sortability, but the other issues are still there. Ultimately, if you need some kind of UUID-compatible representation (eg for Vertica UUID columns), then these are good approaches. If you need to solve the same problems but don't have a reason to be locked into UUIDs, pick something else.