Sortable Collision-Free UUIDs

Cool. I don’t see the readme warning about this, so:

Use wisely and with full awareness. Revealing creation sequence can leak information which can be an issue in scenarios where such information might compromise security.

Are they sortable as a string or as binary? Once you deploy something like this, that becomes important because you'll end up storing binary and string representations in different spots, unless you're _really_ careful (and DBs can insert way faster if you're always doing so near the end of the primary key sorting). And unless you use a totally custom string function, you can't have both, since base64 has letters before numbers, and ASCII is vice versa. It can be a real pain.

4 byte timestamp is brave.

    int(time() - 16 * 10 ** 8)

I think the issue with a lib like this is that people might use it, thinking they don't need the IDs to be secure... until they need to be. But by then plenty would have been generated, and a lot of code would rely on this sortable property.

In fact, I don't see the point of a library like this, it's trying to encode two pieces of information into one string. Why is that? Why not encode geolocation or IP while they're at it. If some data is important, like the order, then a separate database column can easily be used and that would make for a much more durable and reliable solution.

I'd advise UUID v6 over this which is at least an RFC 4122 extension. As coded, this isn't UUID compatible other than being 128 bits.

http://gh.peabody.io/uuidv6/

Also some recent similar submissions:

Timeflake is a 128-bit, roughly-ordered, URL-safe UUID.

https://news.ycombinator.com/item?id=25870482

https://github.com/anthonynsimon/timeflake

ULIDs:

https://news.ycombinator.com/item?id=18768909

Sonyflake:

https://news.ycombinator.com/item?id=25592325

KSUIDs (can't find any discussion here):

https://github.com/segmentio/ksuid

This comment lists other prior art:

https://github.com/bradleypeabody/gouuidv6/issues/3