3 ms·

https://github.com/sixarm/sixarm_ruby_xid https://github.com/sixarm/sixarm_ruby_xid XID is our solution for when collisions do not matter much. XID defintion:

by jph 11y ago

https://github.com/sixarm/sixarm_ruby_xid https://github.com/sixarm/sixarm_ruby_xid XID is our solution for when collisions do not matter much. XID defintion: a 128-bit completely random number, generated from an unblocking source of high security randomness. Example of sources: the OS using /dev/urandom, or the language using a secure random class, etc. XID is compatible with UUID-size-fields in Postgres and any other 128-bit storage system, if you want to save them. The XID idea is quite easy to implement on any system because it's always calling good built-in random tools, rather than trying to home-grow some kind of hash or SHA or masking. The primary advantage is that naming something an XID tells programmers that it's important to use it as intended. Calling a field an XID means: do not use fewer bits, do not use a less-secure randomness source, do not use an UUID library that sets any of the bytes, etc. If you would like to contribute XID code for any language, we welcome commits.

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 ago
  Yes 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.

by jph 11y ago

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 ago
Yes 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.