Hacker News Reader

Comment by qntmfred | Hacker News Reader

any thoughts on uuidv7 vs ulid, nanoid, etc for url-safe encodings?

ULID 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.

A 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.

You need to convert it to perserve the timestamp info correctly so that a ULID library reading the base32 format would reproduce the same timestamp.

What 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.

Nah 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.

I prefer TypeID: https://github.com/jetify-com/typeid

i 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.

Reply on news.ycombinator.com