Seems that someone ported the javascript ulid library to Python: https://github.com/mdipierro/ulid

.. and it appears to be working

I wonder why you would ever want it to be case-insensitive? Surely that increases the possibility of clashes, and violates the very good principle of least surprise (pretty much every other ID in the world is case-sensitive).

Note. You cant compare ULID with UUID's

  - An ulid is "sortable". But the whole point of an UUID is a random unique ID. Non guessable. Sortable is not a feature 
    you normally want from an uuid. And still UUIDs are still sortable. But it doesnt have any meaning. 
  - An ulid also encodes Time, an uuid doesn't. 
  - An uuid has less change of clashing: Its 128 bit vs 80 bit for ulid.
  - An uuid is also url safe.
  - An ulid is case insensitive. I don't see how this is an advantage.

I've been working on a closely related problem of universal identification in distributed computing for a few years now. It's now in standards review and hopefully publishable soon.

We came to the conclusion that universal ids should represent identity only, and explicitly not have 'metadata'. What is the use of 48 bites of time? It reduces the overall entropy, for what? If time is important then why not make the id literally time (i.e. UnixNano), if it isn't they why not make all bits rand?

Also, while I think speak-ability is actually very important (many disagree), I'd assert that capitalization is better addressed from the opposite direction (i.e. UI). Instead of removing capital letters from the ID itself affecting all cases, address the human factors in the few cases it comes up.

I think this is good advice in general:

When spoken aloud we suggest that you don't indicate capitalization at first. In many cases, such as search, human validation etc, this is more than enough precision, then one can add capitalization for disambiguation as needed.

For example:

"ab2Cd3Ef1g"

Spoken becomes: "a b two c d three e f one g. Capitalize 4 and 7, c and e"

With the capitalization part optional depending on context.

Word of caution to anybody looking to use a similar method working with SQL Server: the SQL Server uniqueidentifier type is stored differently on disk than binary(16). Instead of being ordered by bytes 0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15, uniqueidentifier values are ordered by bytes 10-11-12-13-14-15-8-9-7-6-5-4-3-2-1.

> This alphabet excludes the letters I, L, O, and U to avoid confusion and abuse.

Can anyone please ellaborate? I don't get the confusion or abuse potential

Will the ulid be unique even if it is generated from 2 different machines at the same millisecond?