Nanoid Alternatives

nanoid reviews and mentions

• Logging - correlationId - headers - how?
  2 projects | reddit.com/r/nextjs | 30 Jan 2023

  In middleware.ts I can generate a cookie very easily - doing a check to see if the correlationId cookie is set - if it is, use it, if not, use something like nanoid to generated a unique ID.

• Build a URL shortener using React and Node/Express in Typescript
  3 projects | dev.to | 22 Jan 2023

  Every time /shorten-url is called, nanoid generates a URL-friendly key. Then, the key and a long URL are stored in the mapping for URL redirection. And, the key is stored in a SET object to check if the generated key is duplicated. If the key is duplicated, the error will be thrown.

• We Chose NanoIDs for PlanetScale’s API
  6 projects | news.ycombinator.com | 29 Dec 2022

  Just look out for this issue:

  https://github.com/ai/nanoid/issues/365

  6 projects | news.ycombinator.com | 29 Dec 2022

  The seed for an LFSR is just the starting value for its cycle; it can be any value in the cycle, and it's public anyway in that you can think of each output of an LFSR as the "seed" for the next output.

  But in the case of the "taps", yes, you would want to treat those as a secret if you didn't want someone to predict the next value in the cycle. An LFSR by itself might not be a complete solution for IDs for public consumption, but it does neatly solve the need for pseudo-random non-colliding IDs. Whereas NanoIDs are able to generate values with a ~1% probability of collision over some time period, LFSRs can generate values with a 0% probability of collision over their entire bit space. (And they're composable!)

  It looks like NanoIDs are entirely random values reduced to a specific alphabet (https://github.com/ai/nanoid/blob/main/index.js) -- which is approximately similar to:

      tr -dc _A-Z-a-z-0-9 < /dev/urandom | tr -d '/+oO0lLiI1\n\r' | head -c $num_chars

  6 projects | news.ycombinator.com | 29 Dec 2022

  We should consider the following properties when evaluating ID formats and generation algorithms:

  1. Private: you shouldn’t be able to gain information about the system using the IDs from an ID alone. E.g. document enumeration attacks like what happened with Parker (https://www.wired.com/story/parler-hack-data-public-posts-im...)

  2. B-tree/cache friendly: newly created IDs should all exist in a narrow range of values. This is helpful for databases.

  3. Stateless: ideally you shouldn’t need to know the current state of the system to create a new ID.

  4. Human-friendly: IDs should be easily dictated, copied, pasted, etc. This means they should be encodable as text that is short and does not include ambiguous characters.

  Some of the these properties are in conflict. Statelessness is achieved by randomly generating long IDs, but people don’t like reading or typing long IDs.

  Different use cases will need these properties in varying amounts. If you don’t intend to expose the IDs to users, (4) doesn’t matter. Just use long, randomly generated byte strings prepended with the date. Most databases have a UUID type that fits the bill.

  If users are going to be working with IDs, that’s more complicated. If not every document has a user-facing ID, just go with the non-user-facing ID like before, and generate a shorter, random, stateful ID as needed.

  I don’t think NanoID prepends the date, which means it won’t be efficient when inserting large numbers of IDs into a large index. They also default to using ambiguous characters like 1 and I and l. Also no error code. But they are shorter than UUIDs. So it doesn’t meet property (2), and it only kind of meets property (4). NanoIDs are random, so you’re probably safe from enumeration attacks (1). NanoIDs mostly leave Statelessness as a decision for the user. They have a nice tool that helps estimate how long the IDs should be (https://zelark.github.io/nano-id-cc/) for a given collision resistance.

  I think we can do better overall. Bitcoin uses a good encoding scheme called base58check. It generates fairly short IDs and uses an error code at the end. I think it could be refined for non-bitcoin purposes, but it’s already pretty good.

  A 128-bit value like the ASCII string “hackernewstestid” is encoded as “Dtajqjz5pptWcmGrNcwBx7”. It’s about 2/3 the size of the equivalent UUID, even with the (unnecessarily long for this use case) error checking code.

  I’d like to see a small ID standard that meets the above requirements and has a choice for either stateless and long or stateful and short. Maybe another choice for secure random or insecure. But all options would have binary form and a text form. The text form would use something similar to base58check, but probably with a smaller (or user-determined) length for the error code.

• Creating Image Optimizer With Rio
  3 projects | dev.to | 6 Dec 2022

  Rio Docs Zod Github Nanoid Github Sharp Github

• Moving Away from UUIDs
  7 projects | news.ycombinator.com | 21 Nov 2022

  I really like https://github.com/ai/nanoid which is available for a wide range of programming languages. It creates short, random, and URL-safe IDs.

  7 projects | news.ycombinator.com | 21 Nov 2022
• I've cloned a simple VScode using Tauri and ReactJS
  3 projects | dev.to | 4 Nov 2022

  nanoid - unique string ID generator

• rs-nanoid: efficient NanoID generation in Rust
  3 projects | reddit.com/r/rust | 14 Oct 2022

  NanoID is originally a JS project.

• A note from our sponsor - Appwrite
  appwrite.io | 31 Jan 2023

  Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more! Learn more →