Unique Identifiers
Thoughts
- IRIs are identifiers,
- [with k-sortable IDs,] You may be allowing your storage needs to escape abstraction layers.
- "If you ever make these values end-user visible, you are leaking info that you might not realize... why should Alice be allowed to know, to within a second, when Bob created their account? This could be misused, or dangerous, in some applications. "
Possible Solutions
Ulid: 128-bit UUID compatible, with 48 bits timestamp, 80 bits random.
Snowflake: 64-bit, with 41 bits timestamp, 10 bits machine ID, 12 bits per-machine sequence. This may be the oldest, but one of the most relevant as it was invented by Twitter, and both Discord and Instagram are using variations of it.
V6: 128-bit UUID, with 64 bits timestamp (minus 4 bits UUID version embedded in it), 2 bits UUID variant, 14 bits “clock sequence”, and 48 bits random. Has a non-expired IETF draft.
Ksuid (K-Sortable Unique IDentifier): 160-bit, with 32 bits timestamp and 128 bits random. Created by Segment and probably mostly in use internally to them as well.
Stripe IDs: Like ch_1Iyqf42eZvKYlo2C4MIyA80e, are a combination of timestamp and random bits and base62 (-ish) encoded, although I don’t remember the proportions and didn’t spend the time reverse engineering them.
Flake: 128-bit, with 64 bits timestamp, 48 bits machine ID, and 16 bits sequence. Created by Boundary (which is under new management) in Erlang, and best considered deprecated.
Nanoid A tiny (124 bytes), secure, URL-friendly, unique string ID generator for JavaScript