uuid6-ietf-draft VS Hashids.java

https://github.com/uuid6/uuid6-ietf-draft/issues/27

Why not UUIDv7?

What if a new UUID version could be designed that would take the randomness of UUID4 and combine it with a timestamp prefix? This would make the UUID increase overall, but not locally – due to the random postfix. The random part ensures uniqueness when a high generation rate is necessary and also makes the UUIDs hard to predict – it’s not possible to guess the previous, or next UUID. It’s fairly simple to devise a custom UUID scheme, but fortunately, there is a new Internet-Draft (at the time of writing) defining new pseudo-sequential UUID versions that aim to solve exactly this issue: draft-peabody-dispatch-new-uuid-format-04. The current state and progress can be viewed at IETF Datatracker.

Brad Peabody did the original -00 draft, which was discussed as an FYI at an IEFT meeting in March 2020. See [1], around 50 lines from the bottom.

Kyzer Davis has since submitted two further revisions -01 and -02 in April and October 2021. See history in [2].

The current -02 draft is due to expire in April 2022. Presumably Kyzer Davis will try to get it discussed before then.

The GitHub repo tracking these drafts is https://github.com/uuid6/uuid6-ietf-draft/.

[1] https://datatracker.ietf.org/meeting/107/materials/minutes-1...

[2] https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-...

At the moment anyway, that XML link won't render per an XML parsing error. For anyone who wants a quick look at what these XML docs look like here's one for UUID6 [0].

[0] https://github.com/uuid6/uuid6-ietf-draft/blob/master/draft-...

You basically want Hashids but sequential? Why not simple convert a base 10 (0-9) number to hex? (0-F)

I found hashids [1] to be a great compromise between integer ids in the database and copyable non-enumerable strings on the client.

[1] https://hashids.org/

I wonder how this might compare to just storing regular autoincrementing ints in the database, and converting to/from hashids (https://hashids.org/) at the edge. It eliminates the collision concern and stores more compactly at the cost of a tiny amount of encode/decode when processing requests. You’d want to push it down as close to the database layer as possible to avoid inadvertent int ID leaks; I added native hashids support to clickhouse but I’m not sure what other database support might entail.

Since hashids are not really hashes and are not secure at all this is not even achieved. Hashids can be easily decoded without the salt by a simple brute-force attack described by the authors of hashid themselves right on their website: https://hashids.org/

You don't necessarily need to use UUIDs. You could use something like Hashids to generate random strings from your sequential IDs in a reversible way, so that users can't predict what their values will be, but you can decode them as needed.

You should not use UUIDv4 as a primary key. You can use normal int values and then use hashids to make them safe for URL. UUIDv7 might be good to use as well once they are more widely supported as well.