3 ms·

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

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