You Don't Need UUID

• cuid2

  15 1,821 4.1 JavaScript

  Next generation guids. Secure, collision-resistant ids optimized for horizontal scaling and performance.

  

- a "fingerprint" of some number of bytes taken from the same entropy source

[0] https://github.com/paralleldrive/cuid2/blob/fb07094487ba5ad0...

this is an awful lot of work to be doing for each ID, and I'm not how it yields anything superior to a plain old UUID, but maybe I'm just being cynical, idk

• typeid

  15 2,744 8.2 Go

  Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

  

IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable).

[0] https://github.com/jetpack-io/typeid

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• nanoid

  83 23,187 8.3 JavaScript

  A tiny (124 bytes), secure, URL-friendly, unique string ID generator for JavaScript

I usually go for Nano Id for new projects https://github.com/ai/nanoid

• bip39

  768 3,306 3.2 JavaScript

  A web tool for converting BIP39 mnemonic codes

• e16957bf-7d7f-41f1-97f4-98c93a6c3540

  1 - -

Does this help see what's wrong with UUIDs in URLs?

  https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6

• keripy

  1 49 9.4 Python

  Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol

  

• spec

  62 8,648 0.0

  The canonical spec for ulid

  

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• ksuid

  38 4,682 3.1 Go

  K-Sortable Globally Unique IDs

  

• btcutil

  2 472 0.0 Go

  Provides bitcoin-specific convenience functions and types

  

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, and confident there's a better implementation

[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. They should be always be store in memory (in your application, or a DB, or anything else) 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 of data.

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.

• dxid

  2 5 6.6 JavaScript

  A better and safer way to display your primary keys in urls or in your app

you might want to consider an alternative with a base32 encoding with a luhn checksum

https://github.com/tttp/dxid

Suggest a related project