UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp)

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by move-on-by on Wednesday September 17, 2025 @01:17PM (#45278645)

Any version of UUID except v4 on the client side would be a mistake- as you are relying on it to provide extra information such as a timestamp which might be manipulated.

Of course, UUIDv4 on the client side is not without risk either- needing to validate uniqueness and not re-use of some other ID. For the UUIDv7 on client side- you could add some sanity validation- but really I think it’s best avoided.

[ Parent | on HN ]

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by JimDabell on Wednesday September 17, 2025 @01:45PM (#45279010)

There’s a whole bunch of use-cases where the ability for a user to mess with the timestamp is not a problem. Who cares if a user screws up the ordering of items in a collection only they see? But if you can attack the private key by generating many different ciphertexts for the same rand, that might let you defeat the purpose of this masking.

[ Parent | on HN ]

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by move-on-by on Thursday September 18, 2025 @09:38AM (#45289553)

I concede my above comment was speaking in generalities and has plenty of exceptions. However, I do prefer to fallback on safe defaults, and letting the client choose the UUIDv7 could certainly have some unsafe consequences.

[ Parent | on HN ]

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by lazide on Friday September 19, 2025 @05:56AM (#45299828)

What if a broken client implementation uses the same client ‘generated’ UUID (or very similar) for all client requests?

[ Parent | on HN ]