ulid VS ksuid

Our Go ULID package has millisecond precision + monotonic random bytes for disambiguation while preserving ordering within the same millisecond. https://github.com/oklog/ulid

There is no "tests".

There is just a single test. Which only tests the decoding of a single known value. No encoding test.

Go has infrastructure for benchmarking and fuzzing. Use it!

Also, you took code from https://github.com/oklog/ulid/blob/main/ulid.go which has "Copyright 2016 The Oklog Authors" but this is not mentionned in your base32.go.

maybe because of dependencies: https://github.com/oklog/ulid/blob/main/go.mod ??

Universally Unique Lexicographically Sortable Identifier

I'm not concerned too much about the performance or the storage size at this stage. I've checked ulids before posting (more specifically https://github.com/oklog/ulid) but the only difference than a random string (especially if you use them with math.rand) is the timestamp prefix which makes them sortable, but I don't need that (users could use the internal SQLite rowid if they needed to sort by a primary key).

why are you using https://github.com/oklog/ulid to generate a cookie secret?

oklog/ulid to generate IDs. coreos/go-oidc for validating JWTs I get from auth. google/go-cmp for comparing structs in tests (unless the project is already using Testify). spf13/pflag because life's too short for Go's flag handling. getkin/kin-openapi for validating reqests/responses against my OpenAPI spec (in tests).

If you just want to roll with an off-the-shelf library, you can use ULID. There are tons of custom made *flake alternatives. If ULID doesn't fit your purposes, look for others.

OP here - we avoid sequences in all but one part of our application due to a dependency. We use [KSUIDs][1] and UUID v4 in various places. This one "gotcha" applies to any sequence, so it's worth calling out as general advice when running a migration like this.

[1]: https://segment.com/blog/a-brief-history-of-the-uuid/

UUID v4 isn't large enough to prevent collisions, that is why segment.io created https://github.com/segmentio/ksuid which is 160bit vs the 128bit of a UUIDv4.

Assuming you don't need to use UUIDv7 (or any UUID's) then https://github.com/segmentio/ksuid provides a much bigger keyspace. You could just append a string prefix if you wanted to namespace, but the chance of collisions of a KSUID is many times smaller than a UUID of any version.

KSUID's are have temporal-lexicographical order plus 128 bits of entropy, which is more than UUIDv4.

https://github.com/segmentio/ksuid

That's why you use ksuid (https://segment.com/blog/a-brief-history-of-the-uuid/) or, if you're willing to go with a draft spec you could go with the new UUID formats https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bi...

Interesting in more history of UUIDs? Twilio Segment's blog has an amazing history lesson about how they came to be.

I use the ksuid from segment. https://github.com/segmentio/ksuid