3 ms·
any thoughts on uuidv7 vs ulid, nanoid, etc for url-safe encodings?
by qntmfred 1y ago
any thoughts on uuidv7 vs ulid, nanoid, etc for url-safe encodings?
- thewisenerd 1y agoi guess that depends on what you mean by url-safe uuidv7 (-) and nanoid (_-) have special characters which urlencode to themselves. none are small enough that you want someone reading them over the phone; but from a character legibility, ulid makes more sense.
- nikisweeting 1y agoULID is the best balance imo, it's more compact, can be double clicked to select, and case-insensitive so it can be saved on macOS filesystems without conflicts. Now someone should make a UUIDv7 -> ULID adapter lib that 1:1 translates UUIDv7 <-> ULID preserving all the timestamp resolution and randomness bits so we can use the db-level UUIDv7 support to store ULIDs.
- masklinn 1y agoA uuid is a 128b number with a specific structure. You can encode them in base32 if you want, there is no need for any sort of conversion scheme.
- nikisweeting 1y agoYou need to convert it to perserve the timestamp info correctly so that a ULID library reading the base32 format would reproduce the same timestamp.
- masklinn 1y agoWhat I'm saying is that ULID is irrelevant and unnecessary, if you want "double clicked to select, and case-insensitive" you just encode your UUIDs in base32. They're still UUIDs.
- nikisweeting 1y agoNah ULID guarantees some extra stuff as part of its spec beyond UUIDv7, including true sub-millisecond monotonicity and a ceiling of 7ZZZZZZZZZZZZZZZZZZZZZZZZZ. You can convert to base32 to get some of the benefits but they're not exactly the same.
- clintonb 1y agoI prefer TypeID: https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid