191–199 of 199 posts
We have different ideas what 'microservice architecture' means, I guess.
One of the key points of UUIDs is to be able to generate (probably) non-conflicting values without coordination
Earlier quoted context omitted.
Once you get over about 10 characters the chance that the user will skip or repeat a character or misread one goes up. Sometimes when I order parts for my car the site wants the VIN to verify that the parts are correct for that vehicle. I often have to make two or three attempts at entering it to get it right.
Eventually, everyone converges to babble[0], BIP-39[1], mnemonic[2], diceware, pgp-word list or equivalent. [0] https://bohwaz.net/archives/web/Bubble_Babble.html [1] https://iancoleman.io/bip39/ [2] https://web.archive.org/web/20090918202746/http://tothink.co...
1. When dealing with user friendly IDs, it's often important to make sure there are no ambiguous characters. This is a UX requirement for anyone that may need to read an ID and type it in at any point. For example, this means removing certain confusing characters like "0oIi1l5sS", etc. You end up with a much smaller set of characters. In my case, young children were required to type in teacher codes. Needless to say, I had to limit a lot of possible confusing characters.
2. You will have collisions. How do you handle them (ie, retry N times until you get a valid one)? What happens if you can't get a valid one? This happened in a product of mine. We had ~8 character codes that were human readable and type-able and we... ran out of codes.
3. How can you embed more information into the code such as versioning? It's often useful to prefix a code with some info in the event you need to modify it later (such as expand the character set or length)?
I have created a custom unique identifier scheme before. This post doesn't address some of the challenges you come across. 1. When dealing with user friendly IDs, it's often important to make sure there are no ambiguous characters. This is a UX requirement for anyone that may need to read an ID and type it in at any point. For example, this means removing certain confusing characters like "0oIi1l5sS", etc. You end up…
You can shrink the range by using a smaller prime number and throwing on out-of-range input. And then you can offset the output to make sure the base-N encoded value is always D digits long.
No comments on this page about Snowflake IDs. https://en.wikipedia.org/wiki/Snowflake_ID They fit within 64 bits, allow for more than enough processes to handle 10k+ transactions per second, give enough of a timestamp headroom for decades into the future, and where ID generation can be made isolated to each process. They don't work well for anything related to archival work, but you might as well use a regular ID for…
Or UUIDv7, which is designed to solve the same problem
Earlier quoted context omitted.
The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order. My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result look…
Do many use cases need lexical ordering for the encoding of the UUID? (The UUIDs themself would still be ordered; it's just the human/URL/wire encoding that isn't.) Most of the use cases I can think of where I'd want an ordered UUID, I probably wouldn't need to lexically compare the encoding of multiple such IDs (where I can see plenty of utility in the ability to compare the underlying IDs).
Earlier quoted context omitted.
The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order. My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result look…
Do many use cases need lexical ordering for the encoding of the UUID? (The UUIDs themself would still be ordered; it's just the human/URL/wire encoding that isn't.) Most of the use cases I can think of where I'd want an ordered UUID, I probably wouldn't need to lexically compare the encoding of multiple such IDs (where I can see plenty of utility in the ability to compare the underlying IDs).
Earlier quoted context omitted.
> that the average end user cares to be dealing with any random string of numbers and digits. A developer, which I took to be "the user" for the purposes of this writeup, cares. My small concern is that the rand is insufficient to generate a unique enough string (just use a lib like snowflake to get overkill entropy), but I'm sick of having the format at all for inconsequential ids (eg https://www.uuidgenerator.net/…
Also as a developer I really dislike UUIDs because the hyphens make it impossible to double-click copy. It’s a small gripe, but I need to copy IDs multiple times per day and it adds up. Other ID formats like cuid or KSUID don’t have hyphens in their canonical representation, and it makes them far more pleasant to work with
ULIDs don't have this problem, for the record.
Earlier quoted context omitted.
There is no fundamental tech advance that caa make the birthday paradox irrelevant or obsolete, and there never will be.
all of cryptocurrency relies on sha256 the fact that the space is huge, and just ignores collisions. seems to work fine.
Factually, X != hash(X). Sometimes you can make the simplifying assumption that X == hash(X), but only in well-defined contexts, subject to proper risk analysis; never in general, or as a presumption of a system that needs to be correct.