Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need UUID

henvic.dev

Post reply on HN
Print view View original

141–150 of 199 posts

Re: You Don't Need UUID

#141

Post by AdamH12113 »

siva7 wrote: post #95
AdamH12113 wrote: post #78

Earlier quoted context omitted.

> Does it make the URL in the URL bar longer? Yeah, but does that matter? I appreciate shorter URLs any time I copy and paste them, which always involves looking at them and sometimes involves scrolling to the end to remove tracking- and search-related fluff. 128 bits is an absurd amount for a unique ID within a single system. Even 48 bits is very, very large -- enough to provide a unique ID (MAC address) to every Et…

That’s not the only major purpose for a UUID and even if it was, it still would be flat out wrong to claim that almost no application requires that.

Maybe I'm missing something, then? I'm having trouble thinking of applications where it seems like a good idea to generate a permanent ID number completely randomly at all, much less applications that need to let the whole world do so. I can see how Windows device drivers have that requirement, but the point of the article is that even a massive site like YouTube (which doesn't want videos to be randomly discoverable via URL manipulation) does not need anywhere close to 128 bits. What are these applications you speak of?

Re: You Don't Need UUID

#142

Post by richbell »

Petersipoi wrote: post #62
richbell wrote: post #30

Earlier quoted context omitted.

Sure — it's just a weird question to pose when the author specifically provides their opinion on it. It'd be different to say "I don't think it matters".

You're just nitpicking. "Does it matter" is a very reasonable response to someone expressing their opinion.

It's not nitpicking.

If I say "x matters and here's why" and you respond "yeah but does x matter?", you're either not paying attention or being rude and dismissive.

Re: You Don't Need UUID

#143

Post by dgb23 »

afgrant wrote: post #66
dgb23 wrote: post #16

An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance. Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID. In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip. Is it practical to pre-allocate empty entries and reserve a s…

Are there modern databases that can’t readily index on a 128-bit value?

You already got multiple answers explaining the performance issue.

Now in many, typical applications you'd have to scale up quite significantly before this becomes a problem.

But if your application requires you to store small, new entries very quickly, you'll start to notice this even with moderate scale. Disk persistence is often the bottleneck already, and this might make it worse.

Re: You Don't Need UUID

#144

Post by sophiabits »

Supermancho wrote: post #129
emodendroket wrote: post #4

> A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from a user’s perspective. I would challenge the premise we appear to be starting from, that the average end user cares to be dealing with any random string of numbers and digits. GUIDs work well, they’re implem…

> that the average end user cares to be dealing with any random string of numbers and digits. A developer, which I took to be "the user" for the purposes of this writeup, cares. My small concern is that the rand is insufficient to generate a unique enough string (just use a lib like snowflake to get overkill entropy), but I'm sick of having the format at all for inconsequential ids (eg https://www.uuidgenerator.net/…

Also as a developer I really dislike UUIDs because the hyphens make it impossible to double-click copy.

It’s a small gripe, but I need to copy IDs multiple times per day and it adds up. Other ID formats like cuid or KSUID don’t have hyphens in their canonical representation, and it makes them far more pleasant to work with

Re: You Don't Need UUID

#145

Post by hot_gril »

traceroute66 wrote: post #107
bandergirl wrote: post #93

Earlier quoted context omitted.

Yes but that's irrelevant, I used a real URL that you will receive in your texts. It's real life, it happens and it sucks. Let's not normalize it.

No. It's not irrelevant. As you have been told apple.com/iphone = www.amazon.com/dp/B09V3HZ8B5 The rest of what you posted on the Amazon link is tracking bullshit. Now, THAT is irrelevant !

Users aren't expected to manipulate URLs manually. If your URLs have extra stuff, that's what people are going to copy/paste into messages.

Amazon product URLs are looong, but maybe people don't share them enough for Amazon to care. YouTube and Twitter put more effort into making them short.

Re: You Don't Need UUID

#146

Post by WA »

saulpw wrote: post #137
afgrant wrote: post #104

Earlier quoted context omitted.

128 bits versus 64 bits is a deal breaker?

Yes. Even 64 bits is too many, really: at 6 bits per human-recognizable token, it's more than 10 tokens, which is outside the range of what almost any human can keep in their working memory. You can't even hold it in your head long enough to type it in a different window. 128 bits is completely beyond that; when confronted with 128-bits like a UUID, people just give up. Seriously, try actually typing in a UUID someti…

The more important requirement is that the id should not be guessable and not easily be brute-forced (example: YouTube private video listings). Now, what's the minimum required entropy to make it unguessable but also make it short enough to have people tell the id over the phone or something?

Re: You Don't Need UUID

#147

Post by stevesimmons »

ianburrell wrote: post #87
masklinn wrote: post #52

Earlier quoted context omitted.

Maybe use a smaller alphabet though, base64’s can be quite hard to read / spell out / reproduce as it includes confusing pairs. While somewhat less dense, base58 or rfc 4648 base32 mitigate these issues.

Base32 or Base36 have the advantage of using single case which is easier to read out. And no symbols.

The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order.

My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result looks something like '0pydgw5pifvapk5zyhmpso5tx'.

The two other advantages of using this id25 format rather than UUID7 are:

- The id25 format is quite distinct from UUID4. So if you have UUID7s being generated distributedly (rather than centrally) and the UUID7 time-ordering feature is important, it's nice to have a format that a trivial "if '-' in uuid_string..." check will spot.

- Because there are no hyphens or symbols, the whole id25 uuid can be selected in web page with a double click. Whereas a uuid will need a mouse movement to get all 5 parts.

Re: You Don't Need UUID

#148

Post by kiitos »

henvic wrote: post #123
cbarrick wrote: post #82

Earlier quoted context omitted.

The base58 code in the post is wrong, but your version isn't right either. Since the alphabet is 58 characters, each character contains log2(58) bits. Since that's not an integer, the encoding process is a bit more complex than just mapping bits to characters in a table. https://digitalbazaar.github.io/base58-spec/#encode

Hi. I'm the author of the post here. I agree lines 12-14 doesn't do a proper encoding, but that's not what I was after. Would you still say it's still wrong if you consider that my function is not really encoding the string per se, but using rand.Read to generate entropy for what I want to be the final output (random string with the base58 alphabet)?

Your IDs are []byte of len=11. Those bytes can be represented in many ways. You can represent them as hex strings via encoding/hex.EncodeToString(id), or base64 strings via encoding/base64.StdEncoding.EncodeToString(id), or base32 strings via encoding/base32.StdEncoding.EncodeToString(id), or etc.

Looks like the most used base58 package is https://pkg.go.dev/github.com/btcsuite/btcutil/base58, but looking at the implementation [0] I'm not impressed, there's definitely a much better approach.

[0] https://github.com/btcsuite/btcutil/blob/v1.0.2/base58/base5...

But how you encode 11 bytes of data is kind of orthogonal to the important thing, which is that you have 11 bytes of data. Those bytes should be always be stored in memory (in your application, or in your DB, or wherever) as the actual 11 bytes of the ID, and not as a base58 or base64 or JSON or whatever other kind of string that can be decoded to the actual 11 bytes they represent.

Likewise, a UUID shouldn't be stored as a string like "64d3f2e0-a4dc-48d3-98ad-7f09eb3b082f", that's a specific encoding of the actual 16 UUID bytes, you should store, process, etc. those bytes directly.

Re: You Don't Need UUID

#149

Post by kiitos »

stevesimmons wrote: post #147
ianburrell wrote: post #87

Earlier quoted context omitted.

Base32 or Base36 have the advantage of using single case which is easier to read out. And no symbols.

The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order. My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result look…

Crockford base32 works, doesn't it?

Re: You Don't Need UUID

#150

Post by irq-1 »

> This solution uses the human-readable base58 encoding scheme.

How readable is base58 in Arabic or Chinese? I've concluded that only the standard numbers 0123456789, algebra symbols +-/*= and phone symbols #* are universal enough for a global encoding. Any other insights are welcomed!

Post reply on HN