Hacker News Reader

Comment by aftbit | Hacker News Reader

>With the release of UUIDv7 that offers some benefits as ULIDs and are native to Postgres as of December 2024 (see the commit here), it might be better to switch to UUIDv7 in the future if one doesn’t care about URL friendliness.

Yes, I think UUIDv7 would be a much better choice especially because you could continue to use the UUID type in postgres and not need to devolve to text. You could also choose to encode the IDs with base32/58/64 at the edge to make them shorter and more URL friendly, though that adds a complexity to your application in tracking database IDs separately from public IDs.

I wish UUID would specify a more url-friendly standard representation format beyond the hex string with dashes.

View on HN

> encode the IDs with base32/58/64 at the edge to make them shorter

Having tried this I immediately regretted it. Storage is not costly enough to justify the additional pain points that you've correctly identified.

> UUID would specify a more url-friendly standard representation

There's always the 2.25 OID space via URN (urn:oid:2.25.12345...). In which case you encode the underlying integer directly without any grouping punctuation involved.

For the same reason above you should use probably use a single encoding for all use cases, at which point, just using the ugly 8-4-4-4-12 will save you the most trouble.

Not sure why your comment was flagged. I also somewhat regret using base58 UUIDs, but with sufficient DB and app-side helpers, and sufficient discipline to always convert at the edges, it became tolerable. It was the only option I could come up with to retrofit short IDs onto a system designed with UUIDs where a project owner decided our URLs needed to be shorter and prettier late in the development process.

I don't think they're suggesting storing them in base32/58/64, but just having that be how they're presented to the user. We do this in some of our APIs- if the URL has an ID of a specific length we try to turn it into a full UUID first before passing it on to other code. In the postgres database, the ID column is still a UUID type.

What’s wrong with the hex-and-dash representation? It’s the textual representation recommended by RFC 9562, and it’s immediately recognizable as a UUID.

There’s also a URN namespace defined for it, if an absolute URI is needed or if one wants to be more explicit:

    urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

It's too long. That's the only real problem with it. The same UUID in base58 would be:

    Xe22UfxT3rxcKJEAfL5373

Which is 22 characters instead of 36.

Too long with respect to what practical requirements? It’s still shorter than the usual hex representation of a full Git hash for example, and I don’t see calls to encode those as Base58. The dashes also make for a more readable structure.

You get long ugly URLs. The system in work on often has 4-5 of these IDs in the URL, making working with them -- like copying and pasting them, or even extracting the particular id you care about from the path -- cumbersome.

+1 for this, UUIDs in URLs is such a pain. For the app we're working on we went with UUIDs and often have 4+ in the URL as well. So ugly and cumbersome.

Worst part is that you can't double-click on one to highlight the whole thing, you have to drag your cursor over it.

At a previous company, we worked _really_ hard to come up with a "4x4" ID system (i.e. a1b2-c3d4) because they'd often have to be read over the phone. Originally, we worried we'd run out of them but after 15+ years it seems like they're still going strong.

Here's some python code that implements what I discussed:

    def decode_id(id):
        if id is None:
            return None
        return str(uuid.UUID(bytes=base58.b58decode(id)))

    def encode_id(id):
        if id is None:
            return None
        if not isinstance(id, uuid.UUID):
            id = uuid.UUID(hex=id)
        return base58.b58encode(id.bytes)

    def ensure_id(id):
        if id is None:
            return None
        try:
            return decode_id(id)
        except Exception:
            try:
                encode_id(id)
            except Exception:
                return None
            else:
                return id

we encoded the id with a base that removes most vowels (to avoid generating words, potentially offensive ones, and added a checksum to prevent copy paste mistakes

it worked quite well so far

https://dxid.tttp.eu/

We had a Django project using ULIDs and it just caused headache after headache when interacting with Postgres, and we had all sorts of weird extensions to try to get it working that blocked a Django upgrade. I ended up ripping it all out and just using UUIDv7 everywhere, much more standard.

why uuidv7 isn't url-friendly?

It is just too long. It does not include any illegal characters, but it is ~50% larger than it needs to be.

Reply on news.ycombinator.com