4 ms·

The closest that comes to minds is ULID[0]. It is short (26 character base32), 128 bit and lexicographically sortable. I think the reason there's no other popu

The closest that comes to minds is ULID[0]. It is short (26 character base32), 128 bit and lexicographically sortable. I think the reason there's no other popular standard is you give up something. 128 bit gives a pretty low risk of collisions in almost all uses, but as you go smaller you start having to consider the specific scenario and impact, etc, which doesn't work well for a standard. You could use another encoding (eg base64 or base85) to get it shorter, but you start sacrificing other things (case sensitivity, url-safeness) - again, not great for a standard. [0] https://github.com/ulid/spec https://github.com/ulid/spec

djbusby 2y ago
And ULID is translatable to UUID. So, eg, use ULID on display, links, etc and UUID data type in the language/DB
notpushkin 2y ago
For my own project, I went with base32-encoded UUIDv7, prefixed with type name (a la Stripe ids). Compared to ULID, it's still lexicopraphically sortable, but is backed by an actual standard, so a bit more sound IMO. UUIDv7 will only work until year 4147 (compared with ULID's 10889AD), but by then I think we'll have another UUID version we can switch to. Here's my implementation in Python: https://codeberg.org/prettyid/python https://codeberg.org/prettyid/python, https://pypi.org/project/prettyid https://pypi.org/project/prettyid And a rudimentary TypeScript library: https://codeberg.org/prettyid/js https://codeberg.org/prettyid/js, https://npm.im/prettyid https://npm.im/prettyid