No matter how much time we call ocuidml, it will always return the same counter field (in the case, 0000). It doesn't seem right, honestly. We should figure out a way to persist the counter state among shell invocations for such command. Either through a sort of daemon server or local/user configuration might be reasonable. ✌️

Hi,

please take into account I'm by far no crypto-expert, so please bear with me.

I understand the lines

However if I look at line

Any comments? Where is my reasoning going off?

This would make the cuid package portable and functional on Windows 10 environments too, mostly due the cryptographic secure PRNG & high-quality entropy sources support of mirage-crypto on all platforms (Unix, MacOS and Windows).

A bumping of minimal OCaml compiler version (v4.07.0) is needed as well due mirage-crypto-rng library requirements.

Due to security concerns (which also exist in database auto-increment ids, uuid/guid, and most other id standrads), the Cuid standard is now deprecated in favor of Cuid2.

This OCaml library actually performs base-16 (i.e, hexadecimal) conversions. To comply how much possible with the original CUID JS library, we must stick to base-36 conversions.

The lines below are relevant to the context of this issue:

let maximum = int_of_float (36.0 ** 4.0)

...

let hexadecimal number = Printf.sprintf "%.08x" number

There's a mismatch, as it is easily seen. The maximum representation is under base-36, while the actual conversion runs under base-16.

GH Actions is a far better integrated CI/CD solution. With that I would be able to setup different workflows for every platform (Ubuntu/Unix, MacOS and Windows) and track their build status in different markdown badges.

Also, Travis CI is charging open source projects' builds until maintainers enter in touch with Travis CI support team.

It's all due integer overflow. Our implementation relies upon Unix.gettimeofday, which is out of the range of integer representation with OCaml (during the conversion through int_of_float). This OCaml conversion function doesn't detect overflows, and therefore it keeps going, increasing negatively too high floats into low/negative integers.

Possible solutions:

• Use a different approach to take the system time.
• Use a different representation for integers to be encoded into base-36 (maybe int 64-bits?)

The following piece of code is the context of this issue:

let timestamp ( ) =
  ( )
  |> Unix.gettimeofday
  |> int_of_float
  |> base36
  |> adjust8