5 ms·

For years already I've been using UUID v4 (generated from a good random source) then base64url encoded, resulting in a 22 characters/bytes long identifier. The

by bmn__ 9y ago

For years already I've been using UUID v4 (generated from a good random source) then base64url encoded, resulting in a 22 characters/bytes long identifier. The nanoid implementation does not really bring anything new to the table except having fewer SLOC (which I personally don't find important). It is also incompatible with https://tools.ietf.org/html/rfc4648#section-5 https://tools.ietf.org/html/rfc4648#section-5 for no good reason. It is noticable again and again that devs publishing to npm are not up to snuff, I wish I knew why, as this does not happen with other dynamic languages/their code repos.

dchest 9y ago
Wait, why would you base64-encode UUID? You can encode 16 random bytes and not have a few bits spoiled by UUID version number. But then, there are people who'd like to use 62-character alphabet, avoiding any special characters. This package allows them do generate such strings. > devs publishing to npm are not up to snuff Indeed, there are tons of packages that use Math.random or take modulo without accounting for bias. This is why I'm glad there are new packages like nanoid appearing, created by people who know what they are doing, and this is why your negativity is unfounded.
- bmn__ 9y ago
  > why would you base64-encode UUID? You can encode 16 random bytes Because it's a standard data type. It's supported by the database and the data abstraction layers. I can use other implementations for creating, storing and retrieving UUIDs because they backed by the standard and are interoperable. I don't get these advantages with your ad-hoc approach. The loss of 4 bits do not hurt me. > this is why your negativity is unfounded I was criticising the needless deviation from an encoding standard. You talk about how it's good that nanoid picked the correct random algorithm. That just does not fit together.
  - dchest 9y ago
    OK, so you use a non-standard representation of UUIDs because you can convert it to the standard representation for compatibility reasons. Fair enough, it's a good reason to do this if that's what you want. But then you complain that there's a different implementation of generating random identifier strings "not up to snuff", as if we all should settle on old crappy standards and stop creating something new. (One thing I don't understand with many developers is that they insist on doing something one way, thinking that their way is the best one and there should not exist other ways.)
    - wruza 9y ago
      Not because he can, but because me and they can decode and store these values in our far-from-npm environment that never even heard of nanoid. All we need to know is "base64url uuidv4". Irl, when someone tells you their data is nanoid-encoded, it is just pain in the ass, not an improvement in any way. Btw, if you'd remove emotional "old crappy" from the sentence, it would sound pretty sacrastic.
      - dchest 9y ago
        What do you need to decode it for? It's an identifier that you store, no need to decode it. Or do you mean, you want to optimize storage by compressing those identifiers into as little bits as possible? Then just store random bytes and use any encoding you like for outside representation, just like you would do with optimizing UUID storage (except with UUID you're losing a few bits to account for the version indicator, which should not have existed at all if not for the mess with combining a method of creating a pseudorandom byte generator with encoding format, which what various UUID versions are.)
        wruza 9y ago
        I do create, use (compare/lookup) and store uuids, by design. Base64url is just one of possible encoding methods for, as you may have noticed, passing it through url. Other channels may have other [incompatible] limitations or not have these, so there is no need to stick to specific escaping format. Your long story short is: get rid of uuidv4 tag and use smelly format unreadable by virtually anyone outside of your code. Or generate random bytes environment-agnostically by yourself. No, thanks.
        dchest 9y ago
        use smelly format unreadable by virtually anyone outside of your code Aaarrgh. It is readable by everyone! It's an identifier, you don't need to convert it to something else: its conversion is identity function.
watty 9y ago
Good points but this comment reeks of arrogance. It absolutely does occur in other languages, why would you assume it doesn't?
- meddlepal 9y ago
  Can you cite some examples of this in other languages? It seems to occur time and time again in JS-land, but I rarely see other languages bad libraries getting 2000+ GH stars and onto HN with this kind of garbage. FWIW. I have also always done the exact Base64 UUID op suggested when I need a shortened unique identifier...
- sametmax 9y ago
  To be fair, most other high level languages have functions in their stdlib to do common stuff like hashing, generating unique id, getting data from the OS random generator, etc. JS stdlib has always be lacking in almost every possible aspects, and hence people have to reinvent the wheel again and again.
discreteevent 9y ago
Agreed. It's usually better to use a standard if there is one. To be specific its at: https://tools.ietf.org/html/rfc4648#page-7 https://tools.ietf.org/html/rfc4648#page-7 Note that it excludes the use of ~ because it has special meaning in some file systems. Nano ID includes ~. It's a good demonstration of why sometimes a standards comittee is better than a lone developer: A group of people and reviewers are more likely to think of everything.
- irq-1 9y ago
  Base64 isn't URL safe; the equal signs need to be escaped.
  - bmn__ 9y ago
    We're talking about base64url, which is URL safe. Links are in the post you were replying to and its parent.
feedjoelpie 9y ago
> It is noticable again and again that devs publishing to npm are not up to snuff, I wish I knew why, as this does not happen with other dynamic languages/their code repos. It absolutely does happen with other languages. It just happens in Node with greater volume because of the greater volume of programmers, low barriers to entry for JavaScript, lack of a rich standard library, the convergence of server focused coders and frontend coders, and lack of consensus around best practices and frameworks for applications. Kind of the way it's been possible to write decent code in PHP since version 5. Yet the overall ecosystem is still mostly bad. Lots of need to fashion very basic tools + high volume of inexperience + democracy = A package repo full of nonsense where it's difficult to find the diamonds in the rough.

by bmn__ 9y ago

dchest 9y ago

Wait, why would you base64-encode UUID? You can encode 16 random bytes and not have a few bits spoiled by UUID version number. But then, there are people who'd like to use 62-character alphabet, avoiding any special characters. This package allows them do generate such strings. > devs publishing to npm are not up to snuff Indeed, there are tons of packages that use Math.random or take modulo without accounting for bias. This is why I'm glad there are new packages like nanoid appearing, created by people who know what they are doing, and this is why your negativity is unfounded.

bmn__ 9y ago
> why would you base64-encode UUID? You can encode 16 random bytes Because it's a standard data type. It's supported by the database and the data abstraction layers. I can use other implementations for creating, storing and retrieving UUIDs because they backed by the standard and are interoperable. I don't get these advantages with your ad-hoc approach. The loss of 4 bits do not hurt me. > this is why your negativity is unfounded I was criticising the needless deviation from an encoding standard. You talk about how it's good that nanoid picked the correct random algorithm. That just does not fit together.
- dchest 9y ago
  OK, so you use a non-standard representation of UUIDs because you can convert it to the standard representation for compatibility reasons. Fair enough, it's a good reason to do this if that's what you want. But then you complain that there's a different implementation of generating random identifier strings "not up to snuff", as if we all should settle on old crappy standards and stop creating something new. (One thing I don't understand with many developers is that they insist on doing something one way, thinking that their way is the best one and there should not exist other ways.)
  - wruza 9y ago
    Not because he can, but because me and they can decode and store these values in our far-from-npm environment that never even heard of nanoid. All we need to know is "base64url uuidv4". Irl, when someone tells you their data is nanoid-encoded, it is just pain in the ass, not an improvement in any way. Btw, if you'd remove emotional "old crappy" from the sentence, it would sound pretty sacrastic.
    - dchest 9y ago
      What do you need to decode it for? It's an identifier that you store, no need to decode it. Or do you mean, you want to optimize storage by compressing those identifiers into as little bits as possible? Then just store random bytes and use any encoding you like for outside representation, just like you would do with optimizing UUID storage (except with UUID you're losing a few bits to account for the version indicator, which should not have existed at all if not for the mess with combining a method of creating a pseudorandom byte generator with encoding format, which what various UUID versions are.)
      - wruza 9y ago
        I do create, use (compare/lookup) and store uuids, by design. Base64url is just one of possible encoding methods for, as you may have noticed, passing it through url. Other channels may have other [incompatible] limitations or not have these, so there is no need to stick to specific escaping format. Your long story short is: get rid of uuidv4 tag and use smelly format unreadable by virtually anyone outside of your code. Or generate random bytes environment-agnostically by yourself. No, thanks.
        dchest 9y ago
        use smelly format unreadable by virtually anyone outside of your code Aaarrgh. It is readable by everyone! It's an identifier, you don't need to convert it to something else: its conversion is identity function.

watty 9y ago

Good points but this comment reeks of arrogance. It absolutely does occur in other languages, why would you assume it doesn't?

meddlepal 9y ago
Can you cite some examples of this in other languages? It seems to occur time and time again in JS-land, but I rarely see other languages bad libraries getting 2000+ GH stars and onto HN with this kind of garbage. FWIW. I have also always done the exact Base64 UUID op suggested when I need a shortened unique identifier...
sametmax 9y ago
To be fair, most other high level languages have functions in their stdlib to do common stuff like hashing, generating unique id, getting data from the OS random generator, etc. JS stdlib has always be lacking in almost every possible aspects, and hence people have to reinvent the wheel again and again.

discreteevent 9y ago

Agreed. It's usually better to use a standard if there is one. To be specific its at: https://tools.ietf.org/html/rfc4648#page-7 https://tools.ietf.org/html/rfc4648#page-7 Note that it excludes the use of ~ because it has special meaning in some file systems. Nano ID includes ~. It's a good demonstration of why sometimes a standards comittee is better than a lone developer: A group of people and reviewers are more likely to think of everything.

irq-1 9y ago
Base64 isn't URL safe; the equal signs need to be escaped.
- bmn__ 9y ago
  We're talking about base64url, which is URL safe. Links are in the post you were replying to and its parent.

feedjoelpie 9y ago

> It is noticable again and again that devs publishing to npm are not up to snuff, I wish I knew why, as this does not happen with other dynamic languages/their code repos. It absolutely does happen with other languages. It just happens in Node with greater volume because of the greater volume of programmers, low barriers to entry for JavaScript, lack of a rich standard library, the convergence of server focused coders and frontend coders, and lack of consensus around best practices and frameworks for applications. Kind of the way it's been possible to write decent code in PHP since version 5. Yet the overall ecosystem is still mostly bad. Lots of need to fashion very basic tools + high volume of inexperience + democracy = A package repo full of nonsense where it's difficult to find the diamonds in the rough.