31–40 of 376 posts
It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?
UUIDs are 128-bits, not characters. The string representation is just for humans.
Earlier quoted context omitted.
UUIDs are 128-bits, not characters. The string representation is just for humans.
I think the parent is saying that we can make UUIDs more human-readable by displaying the underlying 128 bits with a larger set of characters.
Earlier quoted context omitted.
UUIDs are 128-bits, not characters. The string representation is just for humans.
I think the parent is saying that we can make UUIDs more human-readable by displaying the underlying 128 bits with a larger set of characters.
It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?
UUIDs are 128-bits, not characters. The string representation is just for humans.
The easiest is probably to just base64 the binary representation of the 128 bit number, which results in a 128/6=22 character string, which is a bit smaller.
If glyph-length and not byte-length is more important you could go even smaller but I'm less sure if that's a good idea.
Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implications. (e.g. knowing when session tokens or accounts are created).
Earlier quoted context omitted.
I've been seeing a few different vendors do this already. MongoDB's ObjectIds are inherently timestamps (so you can actually generate generic MongoDB IDs to query based on time). There's also Discord's Snowflakes as well. I'm sure there's loads of others. All it tells you is when something was generated, not much else. I do love how MongoDB has it stored in such a way that it is easy to query against. I wonder if any…
There are definitely many cases where it isn't an issue since you were going to tell the user the time anyway (like sent time on a message)
Can you take the first portion of the UUIDv7 string, and decode it to figure out the exact date and time that record was created? I'm wondering if there might be security/privacy concerns in some situations if the UUID codes are visible in your app?
Half the point of these things is that they’re treated as opaque identifiers.
It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?
If you want to store UUIDs as compactly as possible you'd use 16 bytes.
If you want to store them as text, mapping them to Unicode would be a terrible idea because: many characters are from scripts you've never heard of, many characters look identical (Α vs A), many characters are decomposed and it can change the encoding if they're decomposed[1], &c.