hashids VS Hashids.java

More than 10 years ago, I released the first version of Hashids in PHP, an encoding library to generate unique IDs from numbers [0]. Over the years, many developers have converted the library to plenty of other programming languages. It was nice to see it grow, but there were always a few things that bothered me about the original algorithm, so a few months ago I've decided to try and address those issues.

With lots of help from the community, we've rebranded the library to Sqids (you can see the proposed changes here [1]).

The new library generates unique IDs faster and with a simpler algorithm. You can read all about it on the FAQ page [2] and try it out via the playground [3]. As always, feedback is welcome via HN or Github.

[0] https://github.com/vinkla/hashids/commit/98d72eac456aabbf2da...

Depending on your requirements, you may also want to look at libraries that allow you to generate an ID using an existing identifier such as hashids. Unlike UUIDs (or other random values) these are predictable (if you know enough values and their original IDs, or watch new ones being created, you can reverse-engineer the mapping) but can still serve as a short, obfuscated value.

Sounds like you want hashids

If you want "nice looking" IDs that are unique, you could use HashIds : https://github.com/vinkla/hashids

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.