3 ms·
> for when collisions do not matter much. Collision, in that scheme, are effectively impossible. It's mostly the same as a UUIDv4. (The link notes this, and pe
by deathanatos 11y ago
> for when collisions do not matter much.
Collision, in that scheme, are effectively impossible. It's mostly the same as a UUIDv4. (The link notes this, and perhaps those extra bits are nice; I'm not sure why you'd use a poor PRNG to generate a UUIDv4 as that would effectively be a broken implementation. If you're doing that, what would prevent you from doing the same with XIDs?)
- jph 11y agoYes you're correct. In practice we've seen many codebases that generate UUIDv4 by a poor PRNG or a codebase-seeded PRNG. For example we've seen bash `$RANDOM % 10` instead of /dev/urandom, Java Random instead of SecureRandom, or misinformed home-grown hashing attempts as described in the article, or a constant seed at the top of the code. The UUID spec allows these; the XID spec prohibits these. You asked: what would prevent you from doing a broken implementation of an XID? In a case such as that, an advantage of an XID is a correct implementation is easier to see during code review, easier to verify during continuous integration, and easier to discuss with teams that aren't as familiar with PRNGs, seeds, crypto, and UUID v1-v5. These are people-pragmatic benefits not information-theoretic benefits.