14 ms·

The UX of UUIDs

216 points by jlaneve 3y ago

compressedgas 3y ago
Except that UUIDs by themselves don't do this at all: > They provide a reliable way to ensure that each item, user, or piece of data has a unique identity. It is the registration of a UUID in a database which prohibits reuse that does that. If you aren't do doing that, ensuring that each use of a UUID is not a reuse of an already assigned UUID, they are not UNIQUE.
- umpalumpaaa 2y ago
  Did you read the full article? "Reducing the length of your IDs can be nice, but you need to be careful and ensure your system is protected against ID collissions. Fortunately, this is pretty easy to do in your database layer. In our MySQL database we use IDs mostly as primary key and the database protects us from collisions. In case an ID exists already, we just generate a new one and try again. If our collision rate would go up significantly, we could simply increase the length of all future IDs and we’d be fine."
  - roywiggins 2y ago
    Strictly speaking you can't be sure that your UUIDv4 isn't (by pure luck) also in someone else's database, so it's not guaranteed to be universally unique. It's just very, very likely to be so.
    - partdavid 2y ago
      For some value of "strictly speaking", this is true; but it's not a very relevant value. You can't be "sure" your counter never produces a duplicate, either--strictly speaking--in reality. The bug-free program or the computer that isn't affected by external factors is like the friction-free surface: sometimes useful to think about but not something that exists in reality. And the likelihood of a cosmic ray causing a bit flip or a race condition in the way your counter updates is a lot higher (as in, we see it happen all the time) than the theoretical likelihood of a collision on a sufficiently large and random key.
    - vesinisa 2y ago
      > by pure luck No, even that is not true. If all digital (and non-digital) storage media ever manufactured by humans - meaning all hard drives, tape drives, CDs, DVDs, BluRays etc. ever manufactured to date, and every book and word ever printed or written down. If those ALL were only filled in with UUIDv4s generated from a good random source .. you would still not see even one single collision! UUID collisions are only possible with currently known human technology if your randomness source is not good enough. And it will remain so unless there are some astronomical leaps in digital information storage technology - at least 10 orders of magnitude more storage than currently exists. EDIT: I thought of a way for programmers to mentally visualize how unlikely UUID collisions really are. Let's imagine that in some not-too-distant future, there are 10 billion people on Earth. Each of them are given one thousand CPUs. These CPUs have 1024 cores each, and they run at 10 GHz (clock cycles per second). The CPUs implement a hypothetical instruction that can generate a totally random UUID in one clock cycle. As an experiment, all people on Earth one day decide to program all their thousand CPUs each to run a tight loop that will indefinitely generate UUIDs on all 1024 cores and then immediately discard them. After continuing to run this experiment (whose electicity bill will make Bitcoin look like Earth Hour) all day, 24/7, for about 800 years, the likelihood of one UUID ever having been generated twice will have exceeded 50%.
      - kwantam 2y ago
        I'm sorry to say that your analysis is wildly incorrect. - 10 billion people =~ 2^33 - 1000 CPUs =~ 2^10 - 1024 cores =~ 2^10 - 10 GHz =~ 2^33 So: one second's computation by all of these people is 2^86 UUIDs generated. UUIDs are 128 bits. With probability essentially 1, there will be a collision within one second. The reason is known as the birthday paradox. If you sample random values from a set of size k, after you've chosen about sqrt(k) values you will have chosen the same value twice with probability very close to 1/2. By 10*sqrt(k) samples you'll have found a collision with probability well over 90%. In this case, after sampling 2^64 values you'll have a collision with probability 1/2. That happens in roughly 250 nanoseconds (2^-22 seconds) in your thought experiment. 2^64 sounds like a lot, but in many contexts it's not all that much. Every bitcoin block mined takes well in excess of 2^70 SHA evaluations. Obviously the miners are not dedicated to generating UUID collisions, but if they were they'd easily find thousands of them in the time it takes to mine one block (this neglects the fact that it is much easier to sample a UUID than to evaluate double-SHA256).
- deleted 2y ago
  [deleted]
- wongarsu 2y ago
  If you ensure each UUID is generated to spec, using a good source for the random bits, they are astronomically unlikely to collide without any coordination. Choosing the same 124 bits at random just doesn't happen by chance. Of course you have to deal with the implications of people intentionally colliding UUIDs, so maybe don't generate them client-side.
- tossandthrow 2y ago
  that is not correct and borders wrong. a reason to use uuid (eg v4) is that you can generate id's distributed without fearing collisions. it can happen, but is not likely. so the uniqueness comes from a property of the ID and not the database.
- partdavid 2y ago
  In the real world, the likelihood that a bug in your database engine or ID-hander-outer (a race condition, storage edge case or the like) is a lot higher than the risk of collision on a sufficiently large and random key. The whole point of using UUIDs is that you can generate them locally without central coordination--if you want to coordinate your identifiers, you can use a much friendlier ID length (which is explained in the article).
  - kevincox 2y ago
    But you still need to be wary of malicious collisions. I have seen security vulnerabilities where the client generates a UUID ID and that was inserted into the database. However by picking an ID that corresponded to objects from other users it was possible to gain some access to those objects. So any UUID coming from an untrusted source (like a client application) should be checked for uniqueness. However your client apps can be written assuming that their randomly generated UUIDs never have collisions.
    - echoangle 2y ago
      Why would you let the client generate the IDs? If you have to check them anyways, just generate them on the server and only give the ID to the client.
      - kevincox 2y ago
        It can be very useful for offline work and latency hiding. For example the client can generate data structures with the final IDs then sync them to the server. This can also be useful for implementing idempotent updates. The alternative of having some sort of "placeholder ID" until the sever gets back to you (or you get back online) adds a lot of client complexity.
        echoangle 2y ago
        Can't you just give the client a list of generated IDs on the first request and check if the IDs are from the pregenerated IDs afterwards? That should be a lot cheaper than checking all IDs you ever generated.
- pie_flavor 2y ago
  You'll see your first duplicate already-assigned v4 UUID (anywhere on earth) in a few thousand years.
- vesinisa 2y ago
  What part of "universally unique" in Universally Unique Identifier (UUID) you don't understand? They are specifically designed so that you can generate them locally without fearing collisions. That's like.. their entire point.
  - cryptonector 2y ago
    That's an aspiration, not a guarantee.
    - deleted 2y ago
      [deleted]
- dragonwriter 2y ago
  One of the major motivations for UUIDs is that you can generate them in a decentralized fashion, without central registration, with a very high degree of confidence that they will not be repeated, a very important feature in distributed systems where you don’t want to rely on a either a central point of failure or the need for distributed consensus just to generate an ID for data elements.
shinzui 2y ago
The author seems to be unaware of TypeID. You can use TypeID and ignore this article. https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid
- graypegg 2y ago
  Is this particularly widely used? I don't think I'm aware of TypeID either. I don't see why the author's pretty light solution is inferior to this library.
  - shinzui 2y ago
    Because TypeIDs are compatible with UUIDv7 and are supported by libraries in many languages.
- layer8 2y ago
  Underscore has usability drawbacks.
  - sparklingmango 2y ago
    Like what?
    - taco-hands 2y ago
      It's 'oldskool' _ although, frankly, if someone can't find it on a keyboard, they should be condemned to a life full of auto-correct errors.
      - deleted 2y ago
        [deleted]
    - layer8 2y ago
      Depending on the font, it can collide with underlining (as in hyperlinks). I also once had a case where the dashed line a document viewer displayed for a page break hid underscores that happened to be on the last line of the page, causing the recipient to misinterpret the documentation. In proportional fonts, underscores are generally wider than spaces, creating larger gaps between the underscore-separated parts than between the surrounding space-separated words. E.g. in "AAA BBB_CCC DDD", "AAA"/"BBB" and "CCC"/"DDD" are closer together than "BBB"/"CCC". In some fonts the difference is quite substantial. This makes for incorrect/unintuitive visual grouping. You have to press Shift to type them. On mobile keyboards, underscore is usually one extra layer removed. For voice dictation, it's also longer than "dash" or "minus".
djbusby 2y ago
Can use ULID to "fix" some issues https://github.com/ulid/spec https://github.com/ulid/spec
- fnord123 2y ago
  Ulid should wholly be deprecated now that uuidv7 is available.
  - BiteCode_dev 2y ago
    Ulid have a short representation that uuid7 could use but doesn't define. Also, has UUID7 been standardized already? I thought it was still in the pipeline.
  - dagss 2y ago
    As a Microsoft SQL user (not everyone can choose their DB..), UUIDv7 has the issue that people will (understandably, but ignorantly) store it in "uniqueidentifier", which shuffles bytes around and are no longer sorted on time... .. There is even a specific Microsoft SQL-time-ordererd UUID format which is sorted after byte shuffling.. We store ULID in binary(16). Works nicely. Only difference from UUIDv7 is the version bits..
    - djbusby 2y ago
      Couldn't you put UUIDv7 in byte(16) and get the same feature? I found today a PHP UUID library that does one they call UUIDv8 which has more time (like ULID)
      - dagss 2y ago
        Yes, one could. The problem is most programmers who are not aware of this (probably most), will see the UUID and make assumptions that uniqueidentifier type is the most suited one. They are less likely to take a ULID and store it in binary(16). (Might store it in char(26), which is less storage efficient but is still sorted.) Apart from that I happen to LIKE the fact that I can very quickly see the difference between a random identifier and a sorted identifier, they have quite different characteristics after all.. Although I guess people might eventually get used to the initial bytes being 0 on UUIDv7, or just learn to recognize the version bytes.. On that topic, why are the 8 fixed bits of a UUID not concentrated on the same byte. Perhaps the first one. Huge mistake..
IncreasePosts 2y ago
Why would readability of a UUID matter? At most, users should by copy-pasting them, not reading them or trying to memorize them, so why should I and l and 1 looking similar matter?
- shhsshs 2y ago
  The author mentions UUIDs are hard to copy/paste because of the hyphens.
  - IncreasePosts 2y ago
    Right, and that is a fine idea to get rid of the hypens(personally, I just triple click) - I'm talking about the next section.
  - Terr_ 2y ago
    The easy fix is underscores.
- partdavid 2y ago
  Well, point one of the article is that they're unnecessarily hard to copy-paste.
  - spiderice 2y ago
    And the rest of the article talks about what GP is asking about
- esafak 2y ago
  It could help when you're manually inspecting a list of UUIDs?
AirMax98 2y ago
> TLDR: Please don't do this: https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180... But like... why? This article literally does not explain the benefits beyond copying, they are just assumed. I'm not immediately sold on shorter === better, especially when the updated UUIDs are only marginally shorter and you have now introduced the overhead of a translation layer for one of the most basic building blocks in your application.
- mynameisvlad 2y ago
  I thought it was fairly well reasoned in the article. Let's say you have a customer with that UUID as their ID. Do you expect them to recite their UUID perfectly to you every time? What if they made 5 transactions, each with their own UUIDs and you need to look them up, do you now expect them to read out 6 fairly unwieldy IDs? The article is about the UX of UUIDs. Yes, there's a translation layer and more dev work to implement, but the shorter size and use of non-ambiguous characters is a massive improvement in the usability for the end users.
- eviks 2y ago
  You've added an overhead where it had trivial costs and limited to be handled by professionals to reduce an overhead where it's annoying many more people, including poor customers Also, you don't explain why copying isn't good enough, you just reject the article's reasons
swyx 2y ago
i keep a list of UUID reading and desirable properties here! https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20Notes/uuid%20list.md https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...
- iimblack 2y ago
  This is amazing thank you for sharing.
- mik3y 2y ago
  Nice list, found a couple projects I hadn't seen before. My addition for your consideration: https://github.com/mik3y/django-spicy-id https://github.com/mik3y/django-spicy-id
  - swyx 2y ago
    https://github.com/swyxio/brain/commit/5d978d9b12723f7cb24327a3eb93ab5e4d8d35f8 https://github.com/swyxio/brain/commit/5d978d9b12723f7cb2432...
- esafak 2y ago
  It would be possible to bookmark and refer to individual articles if you'd used gist instead of github.
Terr_ 2y ago
> One way to enhance the usability of unique identifiers is by making them easily copyable. This can be achieved by removing the hyphens from the UUIDs, No! That's throwing the baby out with the bathwater! Removing all separators means rare-but-important manual tasks of transcription or comparison become terrible, since there are no clear chunks. Instead use a different character which doesn't have the same problem, one that most software considers part of the same "word"... such as the classic underscore. For most people, double-clicking on this 123_456_789 will select all 9 important numbers. (And maybe a trailing space, but that's a separate problem.)
- ssl-3 2y ago
  Is there an unambiguous, accepted, monosyllabic way to verbally speak the _ character?
  - mcherm 2y ago
    No. There also isn't one for "w", yet we get by with that as a letter.
    - lelanthran 2y ago
      > There also isn't one for "w", yet we get by with that as a letter. Warning: Tangential rant ahead. I'm teaching my toddler to read (Distar alphabet). Even with the modified alphabet, it's a chore to "know" how to pronounce a letter. 'a' has at least 4 different pronunciations in words used by toddlers: apple, came, eat, bread. All the vowels are like that, and even some consonants ('y' has at the very least: baby, yesterday, cycle, buy) The only well-behaved letter in English is 'x': pronounced the same wherever you see it, as 'cks'[1]. [1] For toddlers, anyway. I doubt a 4-year old would be interested in LaTeX :-)
      - __float 2y ago
        Unless it's at the beginning of a word, like xylophone?
throwaway35777 2y ago
base58 is case sensitive which hinders readability. When devs work with uuids they typically remember the first few letters ("this is guid abc", "that one is guid 1ac"). Hard to do that in base58. The coarsest encoding to have this property is Base32 where it remains easy to memorize first few letters without needing to memorize case.
silvestrov 2y ago
Problem with using base58 is that it uses 24 letters (excl 'I') so you can end up with 4 letter words that the marketing/PR departments does not like. Hexadecimal is safe.
- earthboundkid 2y ago
  I like Crockford 32. It has more letters than hex, but is resistant to swear words. https://www.crockford.com/base32.html https://www.crockford.com/base32.html
  - throwaway35777 2y ago
    > resistant to swear words No it's not. Edit: downvoters, a tame example is 0x72b5473d5a567200.
    - copper-float 2y ago
      I have no idea what that is supposed to say.
      - earthboundkid 2y ago
        You take that hex and turn it into Crockford32 and it says eatmefatass00.
      - deleted 2y ago
        [deleted]
  - vesinisa 2y ago
    Resistant might be a strong word. I can see it only has E, A and Y as vowels which maybe helps a little for English as long as you're not the SATAN himself.
    - throwaway35777 2y ago
      It's also trivially easy to reroll ids until they don't contain a swear.
tlrobinson 2y ago
A couple other potentially desirable properties you could incorporate: - K-sortable: ensures good locality when used as an id in a database (e.x. https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid ) - checksum: primarily useful when an id might be conveyed verbally (e.x. customer support) or transcribed (e.x. Bitcoin wallet backup, BIP-39)
- treyd 2y ago
  The bech32 format is a favorite of mine because it uses an alphabet that's designed to be unambiguous and its checksum is designed specifically to guarantee catching few character mistakes and make it possible to suggest where the mistake likely is. It also has a builtin human-readable purpose prefix at the front. Since it's all lowercase it also fits into the QR alphanumeric mode, which doesn't support mixed case so QR codes of bech32 IDs are more efficient.
  - medstrom 2y ago
    An error-correction code inside the ID?! I love it.
- medstrom 2y ago
  The CUID readme [1] explains that there's no real point to K-sortable on modern hardware: [1] https://github.com/paralleldrive/cuid2?tab=readme-ov-file#note-on-k-sortablesequentialmonotonically-increasing-ids https://github.com/paralleldrive/cuid2?tab=readme-ov-file#no...
  - ndriscoll 2y ago
    The CUID readme is wrong. You can safely ignore anyone who says "cloud-native" while discussing performance unless they're explaining why "cloud-native" architectures are often the worst of all possible designs for performance. In postgres for example, full_page_writes (default on, generally not safe to turn off unless you can be sure your filesystem can guarantee it) means you have to write the entire page to WAL if you write one record. This will make your WAL grow way faster if you're doing random IOs. So right off that bat that's going to be a huge write impact.
TehShrike 2y ago
> One way to enhance the usability of unique identifiers is by making them easily copyable. No matter what your identifiers look like, if you want them to be easily copyable you should add `user-select: all` to the element containing them. If you do this, all of the text will be selected automatically when you click on the element. https://developer.mozilla.org/en-US/docs/Web/CSS/user-select https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
- eternityforest 2y ago
  Additionally, copy buttons are very nice.
- blue_pants 2y ago
  That's true, but there are a lot of places where ids live, but where I can't add `user-select: all`. For example, in terminal (logs), Studio3t (db client) etc.
  - cess11 2y ago
    I find double click to select word, triple to select line or buffer, in surprisingly many contexts. Does this work for you?
    - saurik 2y ago
      The whole point of this article is that double-click to select a word doesn't work with a UUID... though, I think this should just be fixed: I have XTerm set up where double clicking selects a word, triple clicking selects a filename (which can include a hyphen, but not a slash), quadruple clicking selects a URL or path, and quintuple clicking selects the rest of the line.
      - iaaan 2y ago
        The workaround I've landed on is double-click and hold, then drag in the correct direction. Precise enough to just grab the UUID, imprecise enough to be quick and not annoying
sgarland 2y ago
> In our MySQL database we use IDs mostly as primary key Clustered index with random data stored as chars as the PK, what a great time! You will surely not regret this decision later.
- esafak 2y ago
  What do you recommend?
  - sgarland 2y ago
    If you can’t model the table with a natural key (or it would be so large as to inhibit performance), then a simple, normal monotonic integer is best. MySQL even lets you use unsigned ints, so if you use a bigint, you can go all the way up to 2^64-1. For those who think this doesn’t work in distributed systems, it absolutely does – PlanetScale uses them internally [0]. If what is likely the largest MySQL (under Vitess) cluster in the world can manage, yours can too. If this is still untenable, then anything k-sortable (like UUIDv7, as the sibling comment mentioned) is a vast improvement over randomness. Don’t cause B+tree page splits, especially in an RDBMS with a clustering index like MySQL. [0]: https://github.com/planetscale/discussion/discussions/366 https://github.com/planetscale/discussion/discussions/366
    - hot_gril 2y ago
      Even if there's a natural key, serial bigint is usually the best. You can use unique indexes beside that without being stuck with them, and joins are faster on integer pkeys.
      - sgarland 2y ago
        For performance, generally yes. Designing a purely relational model is satisfying, but theory often falls apart in prod. It’s still a good idea, IMO, to think about table design starting as though you have a natural key (composite or singular). It helps develop the schema; you can then drop in a serial/identity/autoincrement column, and use the other relationships as FKs.
logifail 2y ago
Q: What's special about the format of UUIDs compared to, say, an equivalent entropy 128-bit number? For many use cases, the hyphens appear to be utterly irrelevant. https://softwareengineering.stackexchange.com/questions/385524/what-is-the-minimum-length-for-a-uuid https://softwareengineering.stackexchange.com/questions/3855...
__MatrixMan__ 2y ago
An even better UUID UX would cycle through colors when you clicked one and then would overlay the assigned color when you see that same UUID elsewhere. Better to find a needle in a haystack if it's the only one with a pink background.
- coldtea 2y ago
  With any of the entropies mentioned, it's not like you'll find 2 same ids in any pagefull of ids for this to ever matter... It's more like, you used id X in your db and 8 months later another X lands, after billions and billions of rows have been inserted...
  - fireflash38 2y ago
    It's more for tx ids or user ids,which are likely to be used multiple times in logging.
  - deleted 2y ago
    [deleted]
  - __MatrixMan__ 2y ago
    We're not looking for duplicates because we're afraid that probability has failed us. We're looking for duplicates because we have a thing of interest, with a corresponding UUID, and we want to notice where else that thing is involved.
nikeee 2y ago
I built cybertoken [1] for API keys and passwords, not (only) IDs. It is basically the format that GitHub uses for their api keys. Underscores, a prefix, so we can get a better debugging experience and automated secret scanning. It also has a CRC32, so you can check offline if the token candidate is a cybertoken while doing secret scanning. [1]: https://github.com/nikeee/cybertoken https://github.com/nikeee/cybertoken
Daegalus 2y ago
As someone who maintains a UUID library, this is definitely something that has been thought about, especially in the UUIDv6-v8 updates. But it was moved to be considered later as an extension after v6-v8 get approved fully. But all these were talked about and considered before it was punted to a later time. https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/4 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/2 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... But there is always TypeID in the meantime which uses UUIDv7 under the hood: https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: https://github.com/daegalus/snowflakes https://github.com/daegalus/snowflakes
MrBuddyCasino 2y ago
If you expose UUIDs to the user, even if just as part of the URL, encode them as shortUUID: https://github.com/skorokithakis/shortuuid https://github.com/skorokithakis/shortuuid
pimlottc 2y ago
> Try copying this UUID by double-clicking on it Nobody does this. Normal users don't even know this is a thing. I worked on an app that did something like this for placeholders in generated text, and in all our extensive testing and high-touch rollouts, we never saw anyone use it. It's nice that you took the time to think about it, but it's not that important.
- kamikaz1k 2y ago
  I use it, but I’m just me. What was the thing your product did?
  - pimlottc 2y ago
    Without getting too specific, it helped automate report writing for caseworkers by generating blocks of boilerplate text appropriate for each case, with placeholders for the particulars of the case. Sort of like: The applicant is fully employed as a _PROFESSION_ at _NAME_OF_COMPANY_ Our designer excited told us how he specifically used underscores so you could double-click the placeholder and just type over it.
- jtriangle 2y ago
  Exactly. It seems the way they use "users" there is much more accurately said as "Junior Devs", which takes your applicable pool from ~7billion max to "almost noone". Quite literally not worth the trouble.
- medstrom 2y ago
  How about when you long-tap on a touchscreen and it automatically selects the whole word? Double-clicking is just one aspect of the wider principle, that is you make life easier for heuristics of all kinds.
- kiitos 2y ago
  Literally everybody does this. It is actually a critical property of usable IDs!
simonw 2y ago
Related note: Amazon IAM credentials often look something like this (not real): aws_access_key_id = AKIA367COJQOEU3UOE aws_secret_access_key = a7Ed0F80a0AF6606/MQG3+4o/o It's frustrating that you can select the access key by double clicking it but not the secret access key because of those / characters.
- accrual 2y ago
  I agree, that is annoying. It doesn't work for me either. Nice that they specify "secret" in key name though to help prevent pasting the wrong one.
pphysch 2y ago
The UX of UUIDs... should not exist. There are so many great ways to improve UX that don't involve overloading or mangling an internal primary identifier that otherwise follows a standard structure. Use immutable human-readable identifiers like "slugs" and/or "natural keys" in addition to robust primary keys. > TLDR Please don't do this: https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180... That URL is fine, it should just be a 30X to https://company.com/stuff/cute-slug https://company.com/stuff/cute-slug and you should use the user-friendly URL where possible.
- Kwpolska 2y ago
  User-friendly URLs with slugs are useful for blogs and other things commonly linked to. But for many other entities, links will be rare, and the central coordination required would just be a waste of time.
  - pphysch 2y ago
    Great, then this isn't a problem. There is no "central coordination" required to set up URL redirects, by the way.
_akhe 2y ago
Do they really have to be that long? And why can't they just be 4-4-4-4 (I'm sure someone knows). In hobby apps I often .split('-')[0] lol the first 8 is fine (so far)
jcgrillo 2y ago
I'd rather focus on optimizing the size of uuids than their text representation. Shipping uuids around as utf-8 text is silly. They're at most 128bits, so we shouldn't use more than that many. In the case where it's necessary to have a text representation (e.g. in some user interface) I guess it's fine to choose whatever (stable) transformation you like, but the standard ways specified in RFC-4122 (hexadecimal, with or without hyphens) seem like the most foolproof. Regarding the logs search use case, the first "chunk" of a uuid is usually well more than enough for a unique match, IME. Also, I've been burned before in cases where some clever transformation was used to make a uuid look different in text form, because in order to synthesize the actual binary uuid I first have to reverse engineer the transformation--e.g. to find the database record corresponding to some http request log message. That's just annoying, and the polar opposite of "user friendly" for the user story of an engineer trying to figure out what's wrong with the system. So.. I guess my vote is to stick to the standard.
- foxhop 2y ago
  that's where I arrive too
hot_gril 2y ago
"Let’s not pretend like we are Google or AWS who have special needs around this. Any securely generated UUID with 128 bits is more than enough for us." Thank you. This is overthought so much, including with partially-random things like uuid3, 5, 7.
- j16sdiz 2y ago
  You need them when you don't have a quick, secure random source. Like virtual machines or embedded systems.
  - hot_gril 2y ago
    If you don't have RNG, it's natural to think about a non-random UUID.
rickcarlino 2y ago
I’ve always felt that Crockford Base 32 was very ergonomic. http://www.crockford.com/base32.html http://www.crockford.com/base32.html
jongjong 2y ago
This is a great point. It's unfortunate that few engines and standard libraries implement base58 encoding/decoding. This is probably because it is a more complex format because it does not include certain ambiguous letters like l and O. Base64 is relatively straight forward to implement as it maps easily from a number to a character.
briantakita 2y ago
Why is Base58 used instead of Base64?
- spiderice 2y ago
  It removes the ambiguous characters (I, l)
rendall 2y ago
I at first misread "TLDR; Please don't do this:" as applying to the entire article. I read it expecting a kind of McSweeney's parody where it gives you terrible advice. Really confused because the advice was good and not funny.
- simonkagedal 2y ago
  Haha, same here. The UX of TLDRs…
kuon 2y ago
For user facing IDs I made base24 which limit the alphabet further to made it case insensitive. https://www.kuon.ch/post/2020-02-27-base24/ https://www.kuon.ch/post/2020-02-27-base24/
tttp 2y ago
We need to separate the storage format (Postgres and MySQL both have a bigint serial for primary key and it should stay that way) for display, you have various ways to encode that number into something easier for humans, what I prefer: - short word - no offensive words - with a checksum (so we easily spot any copy paste mistake) - not sequential - can be put in a url without extra encoding this is our implementation of that (base32 and luhn code) https://github.com/tttp/dxid https://github.com/tttp/dxid
Leftium 2y ago
TypeScript template literal types can be used to type-check IDs with prefixes: https://hw.leftium.com/#/item/39174998 https://hw.leftium.com/#/item/39174998
pmarreck 2y ago
UUIDv7 is great. The PGP Word List for translating hex into words: exists.
eviks 2y ago
Good points, wish they were specced into the original uuids so you don't need to postprocess (except for prefixes add those are more user-specific)
kazinator 2y ago
You also can't easily copy the word "double-click" by just double-clicking on it. Maybe the browser (and other) UI is wrong about word boundaries.
kazinator 2y ago
Here is a thing I wish would Just Work, everywhere. Given: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. I'd like to, say, double click on consectetur to select it (which works), bt then, while holding Shift, I would like to double click on elit so that the selection of consectetur is preserved, and extended over elit, including adipiscing. The behavior I typically see is that, while holding Shift, the first click will extend the selection to the exact character of elit that I'm pointing at. The second click will then cancel the selection and select all of elit. Like it doesn't mean a damn thing that I'm holding down Shift! Ironically, I can make multiple selections that way using Ctrl in Firefox; Ctrl does modify the semantics of the second click while there is a selection.
veidelis 2y ago
> This can be achieved by removing the hyphens from the UUIDs, allowing users to simply double-click on the identifier to copy it. Triple click can be used.
pyuser583 2y ago
Isn’t there some encoding that encodes bytes as words, or pronounceable letter groupings?

216 points by jlaneve 3y ago

Except that UUIDs by themselves don't do this at all: > They provide a reliable way to ensure that each item, user, or piece of data has a unique identity. It is the registration of a UUID in a database which prohibits reuse that does that. If you aren't do doing that, ensuring that each use of a UUID is not a reuse of an already assigned UUID, they are not UNIQUE.

umpalumpaaa 2y ago
Did you read the full article? "Reducing the length of your IDs can be nice, but you need to be careful and ensure your system is protected against ID collissions. Fortunately, this is pretty easy to do in your database layer. In our MySQL database we use IDs mostly as primary key and the database protects us from collisions. In case an ID exists already, we just generate a new one and try again. If our collision rate would go up significantly, we could simply increase the length of all future IDs and we’d be fine."
- roywiggins 2y ago
  Strictly speaking you can't be sure that your UUIDv4 isn't (by pure luck) also in someone else's database, so it's not guaranteed to be universally unique. It's just very, very likely to be so.
  - partdavid 2y ago
    For some value of "strictly speaking", this is true; but it's not a very relevant value. You can't be "sure" your counter never produces a duplicate, either--strictly speaking--in reality. The bug-free program or the computer that isn't affected by external factors is like the friction-free surface: sometimes useful to think about but not something that exists in reality. And the likelihood of a cosmic ray causing a bit flip or a race condition in the way your counter updates is a lot higher (as in, we see it happen all the time) than the theoretical likelihood of a collision on a sufficiently large and random key.
  - vesinisa 2y ago
    > by pure luck No, even that is not true. If all digital (and non-digital) storage media ever manufactured by humans - meaning all hard drives, tape drives, CDs, DVDs, BluRays etc. ever manufactured to date, and every book and word ever printed or written down. If those ALL were only filled in with UUIDv4s generated from a good random source .. you would still not see even one single collision! UUID collisions are only possible with currently known human technology if your randomness source is not good enough. And it will remain so unless there are some astronomical leaps in digital information storage technology - at least 10 orders of magnitude more storage than currently exists. EDIT: I thought of a way for programmers to mentally visualize how unlikely UUID collisions really are. Let's imagine that in some not-too-distant future, there are 10 billion people on Earth. Each of them are given one thousand CPUs. These CPUs have 1024 cores each, and they run at 10 GHz (clock cycles per second). The CPUs implement a hypothetical instruction that can generate a totally random UUID in one clock cycle. As an experiment, all people on Earth one day decide to program all their thousand CPUs each to run a tight loop that will indefinitely generate UUIDs on all 1024 cores and then immediately discard them. After continuing to run this experiment (whose electicity bill will make Bitcoin look like Earth Hour) all day, 24/7, for about 800 years, the likelihood of one UUID ever having been generated twice will have exceeded 50%.
    - kwantam 2y ago
      I'm sorry to say that your analysis is wildly incorrect. - 10 billion people =~ 2^33 - 1000 CPUs =~ 2^10 - 1024 cores =~ 2^10 - 10 GHz =~ 2^33 So: one second's computation by all of these people is 2^86 UUIDs generated. UUIDs are 128 bits. With probability essentially 1, there will be a collision within one second. The reason is known as the birthday paradox. If you sample random values from a set of size k, after you've chosen about sqrt(k) values you will have chosen the same value twice with probability very close to 1/2. By 10*sqrt(k) samples you'll have found a collision with probability well over 90%. In this case, after sampling 2^64 values you'll have a collision with probability 1/2. That happens in roughly 250 nanoseconds (2^-22 seconds) in your thought experiment. 2^64 sounds like a lot, but in many contexts it's not all that much. Every bitcoin block mined takes well in excess of 2^70 SHA evaluations. Obviously the miners are not dedicated to generating UUID collisions, but if they were they'd easily find thousands of them in the time it takes to mine one block (this neglects the fact that it is much easier to sample a UUID than to evaluate double-SHA256).
deleted 2y ago
[deleted]
wongarsu 2y ago
If you ensure each UUID is generated to spec, using a good source for the random bits, they are astronomically unlikely to collide without any coordination. Choosing the same 124 bits at random just doesn't happen by chance. Of course you have to deal with the implications of people intentionally colliding UUIDs, so maybe don't generate them client-side.
tossandthrow 2y ago
that is not correct and borders wrong. a reason to use uuid (eg v4) is that you can generate id's distributed without fearing collisions. it can happen, but is not likely. so the uniqueness comes from a property of the ID and not the database.
partdavid 2y ago
In the real world, the likelihood that a bug in your database engine or ID-hander-outer (a race condition, storage edge case or the like) is a lot higher than the risk of collision on a sufficiently large and random key. The whole point of using UUIDs is that you can generate them locally without central coordination--if you want to coordinate your identifiers, you can use a much friendlier ID length (which is explained in the article).
- kevincox 2y ago
  But you still need to be wary of malicious collisions. I have seen security vulnerabilities where the client generates a UUID ID and that was inserted into the database. However by picking an ID that corresponded to objects from other users it was possible to gain some access to those objects. So any UUID coming from an untrusted source (like a client application) should be checked for uniqueness. However your client apps can be written assuming that their randomly generated UUIDs never have collisions.
  - echoangle 2y ago
    Why would you let the client generate the IDs? If you have to check them anyways, just generate them on the server and only give the ID to the client.
    - kevincox 2y ago
      It can be very useful for offline work and latency hiding. For example the client can generate data structures with the final IDs then sync them to the server. This can also be useful for implementing idempotent updates. The alternative of having some sort of "placeholder ID" until the sever gets back to you (or you get back online) adds a lot of client complexity.
      - echoangle 2y ago
        Can't you just give the client a list of generated IDs on the first request and check if the IDs are from the pregenerated IDs afterwards? That should be a lot cheaper than checking all IDs you ever generated.
pie_flavor 2y ago
You'll see your first duplicate already-assigned v4 UUID (anywhere on earth) in a few thousand years.
vesinisa 2y ago
What part of "universally unique" in Universally Unique Identifier (UUID) you don't understand? They are specifically designed so that you can generate them locally without fearing collisions. That's like.. their entire point.
- cryptonector 2y ago
  That's an aspiration, not a guarantee.
  - deleted 2y ago
    [deleted]
dragonwriter 2y ago
One of the major motivations for UUIDs is that you can generate them in a decentralized fashion, without central registration, with a very high degree of confidence that they will not be repeated, a very important feature in distributed systems where you don’t want to rely on a either a central point of failure or the need for distributed consensus just to generate an ID for data elements.

shinzui 2y ago

The author seems to be unaware of TypeID. You can use TypeID and ignore this article. https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid

graypegg 2y ago
Is this particularly widely used? I don't think I'm aware of TypeID either. I don't see why the author's pretty light solution is inferior to this library.
- shinzui 2y ago
  Because TypeIDs are compatible with UUIDv7 and are supported by libraries in many languages.
layer8 2y ago
Underscore has usability drawbacks.
- sparklingmango 2y ago
  Like what?
  - taco-hands 2y ago
    It's 'oldskool' _ although, frankly, if someone can't find it on a keyboard, they should be condemned to a life full of auto-correct errors.
    - deleted 2y ago
      [deleted]
  - layer8 2y ago
    Depending on the font, it can collide with underlining (as in hyperlinks). I also once had a case where the dashed line a document viewer displayed for a page break hid underscores that happened to be on the last line of the page, causing the recipient to misinterpret the documentation. In proportional fonts, underscores are generally wider than spaces, creating larger gaps between the underscore-separated parts than between the surrounding space-separated words. E.g. in "AAA BBB_CCC DDD", "AAA"/"BBB" and "CCC"/"DDD" are closer together than "BBB"/"CCC". In some fonts the difference is quite substantial. This makes for incorrect/unintuitive visual grouping. You have to press Shift to type them. On mobile keyboards, underscore is usually one extra layer removed. For voice dictation, it's also longer than "dash" or "minus".

djbusby 2y ago

Can use ULID to "fix" some issues https://github.com/ulid/spec https://github.com/ulid/spec

fnord123 2y ago
Ulid should wholly be deprecated now that uuidv7 is available.
- BiteCode_dev 2y ago
  Ulid have a short representation that uuid7 could use but doesn't define. Also, has UUID7 been standardized already? I thought it was still in the pipeline.
- dagss 2y ago
  As a Microsoft SQL user (not everyone can choose their DB..), UUIDv7 has the issue that people will (understandably, but ignorantly) store it in "uniqueidentifier", which shuffles bytes around and are no longer sorted on time... .. There is even a specific Microsoft SQL-time-ordererd UUID format which is sorted after byte shuffling.. We store ULID in binary(16). Works nicely. Only difference from UUIDv7 is the version bits..
  - djbusby 2y ago
    Couldn't you put UUIDv7 in byte(16) and get the same feature? I found today a PHP UUID library that does one they call UUIDv8 which has more time (like ULID)
    - dagss 2y ago
      Yes, one could. The problem is most programmers who are not aware of this (probably most), will see the UUID and make assumptions that uniqueidentifier type is the most suited one. They are less likely to take a ULID and store it in binary(16). (Might store it in char(26), which is less storage efficient but is still sorted.) Apart from that I happen to LIKE the fact that I can very quickly see the difference between a random identifier and a sorted identifier, they have quite different characteristics after all.. Although I guess people might eventually get used to the initial bytes being 0 on UUIDv7, or just learn to recognize the version bytes.. On that topic, why are the 8 fixed bits of a UUID not concentrated on the same byte. Perhaps the first one. Huge mistake..

IncreasePosts 2y ago

Why would readability of a UUID matter? At most, users should by copy-pasting them, not reading them or trying to memorize them, so why should I and l and 1 looking similar matter?

shhsshs 2y ago
The author mentions UUIDs are hard to copy/paste because of the hyphens.
- IncreasePosts 2y ago
  Right, and that is a fine idea to get rid of the hypens(personally, I just triple click) - I'm talking about the next section.
- Terr_ 2y ago
  The easy fix is underscores.
partdavid 2y ago
Well, point one of the article is that they're unnecessarily hard to copy-paste.
- spiderice 2y ago
  And the rest of the article talks about what GP is asking about
esafak 2y ago
It could help when you're manually inspecting a list of UUIDs?

AirMax98 2y ago

> TLDR: Please don't do this: https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180... But like... why? This article literally does not explain the benefits beyond copying, they are just assumed. I'm not immediately sold on shorter === better, especially when the updated UUIDs are only marginally shorter and you have now introduced the overhead of a translation layer for one of the most basic building blocks in your application.

mynameisvlad 2y ago
I thought it was fairly well reasoned in the article. Let's say you have a customer with that UUID as their ID. Do you expect them to recite their UUID perfectly to you every time? What if they made 5 transactions, each with their own UUIDs and you need to look them up, do you now expect them to read out 6 fairly unwieldy IDs? The article is about the UX of UUIDs. Yes, there's a translation layer and more dev work to implement, but the shorter size and use of non-ambiguous characters is a massive improvement in the usability for the end users.
eviks 2y ago
You've added an overhead where it had trivial costs and limited to be handled by professionals to reduce an overhead where it's annoying many more people, including poor customers Also, you don't explain why copying isn't good enough, you just reject the article's reasons

swyx 2y ago

i keep a list of UUID reading and desirable properties here! https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20Notes/uuid%20list.md https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...

iimblack 2y ago
This is amazing thank you for sharing.
mik3y 2y ago
Nice list, found a couple projects I hadn't seen before. My addition for your consideration: https://github.com/mik3y/django-spicy-id https://github.com/mik3y/django-spicy-id
- swyx 2y ago
  https://github.com/swyxio/brain/commit/5d978d9b12723f7cb24327a3eb93ab5e4d8d35f8 https://github.com/swyxio/brain/commit/5d978d9b12723f7cb2432...
esafak 2y ago
It would be possible to bookmark and refer to individual articles if you'd used gist instead of github.

Terr_ 2y ago

> One way to enhance the usability of unique identifiers is by making them easily copyable. This can be achieved by removing the hyphens from the UUIDs, No! That's throwing the baby out with the bathwater! Removing all separators means rare-but-important manual tasks of transcription or comparison become terrible, since there are no clear chunks. Instead use a different character which doesn't have the same problem, one that most software considers part of the same "word"... such as the classic underscore. For most people, double-clicking on this 123_456_789 will select all 9 important numbers. (And maybe a trailing space, but that's a separate problem.)

ssl-3 2y ago
Is there an unambiguous, accepted, monosyllabic way to verbally speak the _ character?
- mcherm 2y ago
  No. There also isn't one for "w", yet we get by with that as a letter.
  - lelanthran 2y ago
    > There also isn't one for "w", yet we get by with that as a letter. Warning: Tangential rant ahead. I'm teaching my toddler to read (Distar alphabet). Even with the modified alphabet, it's a chore to "know" how to pronounce a letter. 'a' has at least 4 different pronunciations in words used by toddlers: apple, came, eat, bread. All the vowels are like that, and even some consonants ('y' has at the very least: baby, yesterday, cycle, buy) The only well-behaved letter in English is 'x': pronounced the same wherever you see it, as 'cks'[1]. [1] For toddlers, anyway. I doubt a 4-year old would be interested in LaTeX :-)
    - __float 2y ago
      Unless it's at the beginning of a word, like xylophone?

throwaway35777 2y ago

base58 is case sensitive which hinders readability. When devs work with uuids they typically remember the first few letters ("this is guid abc", "that one is guid 1ac"). Hard to do that in base58. The coarsest encoding to have this property is Base32 where it remains easy to memorize first few letters without needing to memorize case.

silvestrov 2y ago

Problem with using base58 is that it uses 24 letters (excl 'I') so you can end up with 4 letter words that the marketing/PR departments does not like. Hexadecimal is safe.

earthboundkid 2y ago
I like Crockford 32. It has more letters than hex, but is resistant to swear words. https://www.crockford.com/base32.html https://www.crockford.com/base32.html
- throwaway35777 2y ago
  > resistant to swear words No it's not. Edit: downvoters, a tame example is 0x72b5473d5a567200.
  - copper-float 2y ago
    I have no idea what that is supposed to say.
    - earthboundkid 2y ago
      You take that hex and turn it into Crockford32 and it says eatmefatass00.
    - deleted 2y ago
      [deleted]
- vesinisa 2y ago
  Resistant might be a strong word. I can see it only has E, A and Y as vowels which maybe helps a little for English as long as you're not the SATAN himself.
  - throwaway35777 2y ago
    It's also trivially easy to reroll ids until they don't contain a swear.

tlrobinson 2y ago

A couple other potentially desirable properties you could incorporate: - K-sortable: ensures good locality when used as an id in a database (e.x. https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid ) - checksum: primarily useful when an id might be conveyed verbally (e.x. customer support) or transcribed (e.x. Bitcoin wallet backup, BIP-39)

treyd 2y ago
The bech32 format is a favorite of mine because it uses an alphabet that's designed to be unambiguous and its checksum is designed specifically to guarantee catching few character mistakes and make it possible to suggest where the mistake likely is. It also has a builtin human-readable purpose prefix at the front. Since it's all lowercase it also fits into the QR alphanumeric mode, which doesn't support mixed case so QR codes of bech32 IDs are more efficient.
- medstrom 2y ago
  An error-correction code inside the ID?! I love it.
medstrom 2y ago
The CUID readme [1] explains that there's no real point to K-sortable on modern hardware: [1] https://github.com/paralleldrive/cuid2?tab=readme-ov-file#note-on-k-sortablesequentialmonotonically-increasing-ids https://github.com/paralleldrive/cuid2?tab=readme-ov-file#no...
- ndriscoll 2y ago
  The CUID readme is wrong. You can safely ignore anyone who says "cloud-native" while discussing performance unless they're explaining why "cloud-native" architectures are often the worst of all possible designs for performance. In postgres for example, full_page_writes (default on, generally not safe to turn off unless you can be sure your filesystem can guarantee it) means you have to write the entire page to WAL if you write one record. This will make your WAL grow way faster if you're doing random IOs. So right off that bat that's going to be a huge write impact.

TehShrike 2y ago

> One way to enhance the usability of unique identifiers is by making them easily copyable. No matter what your identifiers look like, if you want them to be easily copyable you should add `user-select: all` to the element containing them. If you do this, all of the text will be selected automatically when you click on the element. https://developer.mozilla.org/en-US/docs/Web/CSS/user-select https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

eternityforest 2y ago
Additionally, copy buttons are very nice.
blue_pants 2y ago
That's true, but there are a lot of places where ids live, but where I can't add `user-select: all`. For example, in terminal (logs), Studio3t (db client) etc.
- cess11 2y ago
  I find double click to select word, triple to select line or buffer, in surprisingly many contexts. Does this work for you?
  - saurik 2y ago
    The whole point of this article is that double-click to select a word doesn't work with a UUID... though, I think this should just be fixed: I have XTerm set up where double clicking selects a word, triple clicking selects a filename (which can include a hyphen, but not a slash), quadruple clicking selects a URL or path, and quintuple clicking selects the rest of the line.
    - iaaan 2y ago
      The workaround I've landed on is double-click and hold, then drag in the correct direction. Precise enough to just grab the UUID, imprecise enough to be quick and not annoying

sgarland 2y ago

> In our MySQL database we use IDs mostly as primary key Clustered index with random data stored as chars as the PK, what a great time! You will surely not regret this decision later.

esafak 2y ago
What do you recommend?
- sgarland 2y ago
  If you can’t model the table with a natural key (or it would be so large as to inhibit performance), then a simple, normal monotonic integer is best. MySQL even lets you use unsigned ints, so if you use a bigint, you can go all the way up to 2^64-1. For those who think this doesn’t work in distributed systems, it absolutely does – PlanetScale uses them internally [0]. If what is likely the largest MySQL (under Vitess) cluster in the world can manage, yours can too. If this is still untenable, then anything k-sortable (like UUIDv7, as the sibling comment mentioned) is a vast improvement over randomness. Don’t cause B+tree page splits, especially in an RDBMS with a clustering index like MySQL. [0]: https://github.com/planetscale/discussion/discussions/366 https://github.com/planetscale/discussion/discussions/366
  - hot_gril 2y ago
    Even if there's a natural key, serial bigint is usually the best. You can use unique indexes beside that without being stuck with them, and joins are faster on integer pkeys.
    - sgarland 2y ago
      For performance, generally yes. Designing a purely relational model is satisfying, but theory often falls apart in prod. It’s still a good idea, IMO, to think about table design starting as though you have a natural key (composite or singular). It helps develop the schema; you can then drop in a serial/identity/autoincrement column, and use the other relationships as FKs.

logifail 2y ago

Q: What's special about the format of UUIDs compared to, say, an equivalent entropy 128-bit number? For many use cases, the hyphens appear to be utterly irrelevant. https://softwareengineering.stackexchange.com/questions/385524/what-is-the-minimum-length-for-a-uuid https://softwareengineering.stackexchange.com/questions/3855...

__MatrixMan__ 2y ago

An even better UUID UX would cycle through colors when you clicked one and then would overlay the assigned color when you see that same UUID elsewhere. Better to find a needle in a haystack if it's the only one with a pink background.

coldtea 2y ago
With any of the entropies mentioned, it's not like you'll find 2 same ids in any pagefull of ids for this to ever matter... It's more like, you used id X in your db and 8 months later another X lands, after billions and billions of rows have been inserted...
- fireflash38 2y ago
  It's more for tx ids or user ids,which are likely to be used multiple times in logging.
- deleted 2y ago
  [deleted]
- __MatrixMan__ 2y ago
  We're not looking for duplicates because we're afraid that probability has failed us. We're looking for duplicates because we have a thing of interest, with a corresponding UUID, and we want to notice where else that thing is involved.

nikeee 2y ago

I built cybertoken [1] for API keys and passwords, not (only) IDs. It is basically the format that GitHub uses for their api keys. Underscores, a prefix, so we can get a better debugging experience and automated secret scanning. It also has a CRC32, so you can check offline if the token candidate is a cybertoken while doing secret scanning. [1]: https://github.com/nikeee/cybertoken https://github.com/nikeee/cybertoken

Daegalus 2y ago

As someone who maintains a UUID library, this is definitely something that has been thought about, especially in the UUIDv6-v8 updates. But it was moved to be considered later as an extension after v6-v8 get approved fully. But all these were talked about and considered before it was punted to a later time. https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/4 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/2 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... But there is always TypeID in the meantime which uses UUIDv7 under the hood: https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: https://github.com/daegalus/snowflakes https://github.com/daegalus/snowflakes

MrBuddyCasino 2y ago

If you expose UUIDs to the user, even if just as part of the URL, encode them as shortUUID: https://github.com/skorokithakis/shortuuid https://github.com/skorokithakis/shortuuid

pimlottc 2y ago

> Try copying this UUID by double-clicking on it Nobody does this. Normal users don't even know this is a thing. I worked on an app that did something like this for placeholders in generated text, and in all our extensive testing and high-touch rollouts, we never saw anyone use it. It's nice that you took the time to think about it, but it's not that important.

kamikaz1k 2y ago
I use it, but I’m just me. What was the thing your product did?
- pimlottc 2y ago
  Without getting too specific, it helped automate report writing for caseworkers by generating blocks of boilerplate text appropriate for each case, with placeholders for the particulars of the case. Sort of like: The applicant is fully employed as a _PROFESSION_ at _NAME_OF_COMPANY_ Our designer excited told us how he specifically used underscores so you could double-click the placeholder and just type over it.
jtriangle 2y ago
Exactly. It seems the way they use "users" there is much more accurately said as "Junior Devs", which takes your applicable pool from ~7billion max to "almost noone". Quite literally not worth the trouble.
medstrom 2y ago
How about when you long-tap on a touchscreen and it automatically selects the whole word? Double-clicking is just one aspect of the wider principle, that is you make life easier for heuristics of all kinds.
kiitos 2y ago
Literally everybody does this. It is actually a critical property of usable IDs!

simonw 2y ago

Related note: Amazon IAM credentials often look something like this (not real): aws_access_key_id = AKIA367COJQOEU3UOE aws_secret_access_key = a7Ed0F80a0AF6606/MQG3+4o/o It's frustrating that you can select the access key by double clicking it but not the secret access key because of those / characters.

accrual 2y ago
I agree, that is annoying. It doesn't work for me either. Nice that they specify "secret" in key name though to help prevent pasting the wrong one.

pphysch 2y ago

The UX of UUIDs... should not exist. There are so many great ways to improve UX that don't involve overloading or mangling an internal primary identifier that otherwise follows a standard structure. Use immutable human-readable identifiers like "slugs" and/or "natural keys" in addition to robust primary keys. > TLDR Please don't do this: https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180... That URL is fine, it should just be a 30X to https://company.com/stuff/cute-slug https://company.com/stuff/cute-slug and you should use the user-friendly URL where possible.

Kwpolska 2y ago
User-friendly URLs with slugs are useful for blogs and other things commonly linked to. But for many other entities, links will be rare, and the central coordination required would just be a waste of time.
- pphysch 2y ago
  Great, then this isn't a problem. There is no "central coordination" required to set up URL redirects, by the way.

_akhe 2y ago

Do they really have to be that long? And why can't they just be 4-4-4-4 (I'm sure someone knows). In hobby apps I often .split('-')[0] lol the first 8 is fine (so far)

jcgrillo 2y ago

I'd rather focus on optimizing the size of uuids than their text representation. Shipping uuids around as utf-8 text is silly. They're at most 128bits, so we shouldn't use more than that many. In the case where it's necessary to have a text representation (e.g. in some user interface) I guess it's fine to choose whatever (stable) transformation you like, but the standard ways specified in RFC-4122 (hexadecimal, with or without hyphens) seem like the most foolproof. Regarding the logs search use case, the first "chunk" of a uuid is usually well more than enough for a unique match, IME. Also, I've been burned before in cases where some clever transformation was used to make a uuid look different in text form, because in order to synthesize the actual binary uuid I first have to reverse engineer the transformation--e.g. to find the database record corresponding to some http request log message. That's just annoying, and the polar opposite of "user friendly" for the user story of an engineer trying to figure out what's wrong with the system. So.. I guess my vote is to stick to the standard.

foxhop 2y ago
that's where I arrive too

hot_gril 2y ago

"Let’s not pretend like we are Google or AWS who have special needs around this. Any securely generated UUID with 128 bits is more than enough for us." Thank you. This is overthought so much, including with partially-random things like uuid3, 5, 7.

j16sdiz 2y ago
You need them when you don't have a quick, secure random source. Like virtual machines or embedded systems.
- hot_gril 2y ago
  If you don't have RNG, it's natural to think about a non-random UUID.

rickcarlino 2y ago

I’ve always felt that Crockford Base 32 was very ergonomic. http://www.crockford.com/base32.html http://www.crockford.com/base32.html

jongjong 2y ago

This is a great point. It's unfortunate that few engines and standard libraries implement base58 encoding/decoding. This is probably because it is a more complex format because it does not include certain ambiguous letters like l and O. Base64 is relatively straight forward to implement as it maps easily from a number to a character.

briantakita 2y ago

Why is Base58 used instead of Base64?

spiderice 2y ago
It removes the ambiguous characters (I, l)

rendall 2y ago

I at first misread "TLDR; Please don't do this:" as applying to the entire article. I read it expecting a kind of McSweeney's parody where it gives you terrible advice. Really confused because the advice was good and not funny.

simonkagedal 2y ago
Haha, same here. The UX of TLDRs…

kuon 2y ago

For user facing IDs I made base24 which limit the alphabet further to made it case insensitive. https://www.kuon.ch/post/2020-02-27-base24/ https://www.kuon.ch/post/2020-02-27-base24/

tttp 2y ago

We need to separate the storage format (Postgres and MySQL both have a bigint serial for primary key and it should stay that way) for display, you have various ways to encode that number into something easier for humans, what I prefer: - short word - no offensive words - with a checksum (so we easily spot any copy paste mistake) - not sequential - can be put in a url without extra encoding this is our implementation of that (base32 and luhn code) https://github.com/tttp/dxid https://github.com/tttp/dxid

Leftium 2y ago

TypeScript template literal types can be used to type-check IDs with prefixes: https://hw.leftium.com/#/item/39174998 https://hw.leftium.com/#/item/39174998

pmarreck 2y ago

UUIDv7 is great. The PGP Word List for translating hex into words: exists.

eviks 2y ago

Good points, wish they were specced into the original uuids so you don't need to postprocess (except for prefixes add those are more user-specific)

kazinator 2y ago

You also can't easily copy the word "double-click" by just double-clicking on it. Maybe the browser (and other) UI is wrong about word boundaries.

kazinator 2y ago

Here is a thing I wish would Just Work, everywhere. Given: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. I'd like to, say, double click on consectetur to select it (which works), bt then, while holding Shift, I would like to double click on elit so that the selection of consectetur is preserved, and extended over elit, including adipiscing. The behavior I typically see is that, while holding Shift, the first click will extend the selection to the exact character of elit that I'm pointing at. The second click will then cancel the selection and select all of elit. Like it doesn't mean a damn thing that I'm holding down Shift! Ironically, I can make multiple selections that way using Ctrl in Firefox; Ctrl does modify the semantics of the second click while there is a selection.

veidelis 2y ago

> This can be achieved by removing the hyphens from the UUIDs, allowing users to simply double-click on the identifier to copy it. Triple click can be used.

pyuser583 2y ago

Isn’t there some encoding that encodes bytes as words, or pronounceable letter groupings?