[robertclaus]

This type of key editing always makes me nervous. I know how uuids behave. I'm not a security expert, but I'm 99% sure the formatting steps here don't increase the chance of key collisions or security implications significantly. Is that 1% risk worth it?

[jalk]

I'm 99.9999% sure that your 1% risk is incorrect, given they are just reformatting UUIDv7

[ramchip]

There's a 1:1 mapping (a bijection) between uuid and uuidkeys, therefore there are as many possible uuidkeys as there are uuids, and the risk of collision is the same.

[jaccola]

I agree - the reformatted IDs are shorter than the originals, so by the pigeonhole principle you are increasing the chance of collision.

I doubt this matters in reality for this case, but the number of comments stating "there is no difference" or something to this effect shows how any added step can easily be misunderstood and could (in the worst case) introduce a fatal security flaw.

[ramchip]

UUIDs are longer because they use a less efficient encoding (base16 vs base32), not because they contain more entropy.

[Merad]

Base 32 is just an encoding, so it doesn't modify the underlying data of the uuid, it presents the data in a different display format. It's the same as how the number 10 can be represented as decimal 10, binary 0b1010, octal 0o12, hex 0xA, etc.