This is probably the last time 😅

The return type of the Decode method has changed from int[] to IReadOnlyList<int> (to eliminate unnecessary memory allocation); so the code snippets on the .NET page of the site need to be updated to:

var sqids = new SqidsEncoder<int>();
var id = sqids.Encode(1, 2, 3); // "86Rf07"
var numbers = sqids.Decode(id); // [1, 2, 3]

var sqids = new SqidsEncoder<int>(new()
{
    Alphabet = "FxnXM1kBN6cuhsAvjW3Co7l2RePyY8DwaU04Tzt9fHQrqSVKdpimLGIJOgb5ZE"
});
var id = sqids.Encode(1, 2, 3); // "B4aajs"
var numbers = sqids.Decode(id); // [1, 2, 3]

var sqids = new SqidsEncoder<int>(new()
{
    MinLength = 10
});
var id = sqids.Encode(1, 2, 3); // "86Rf07xd4z"
var numbers = sqids.Decode(id); // [1, 2, 3]

I have created an implementation in ClojureScript. If you make a sqids-cljs blank repo I will fork it and create a pull request.

Since the initial library has been out for a few weeks, I got to mess around with it a bit more and realized there are a few rough edges we could iron out:

1. Lower reserved characters count from 3 to 1 (more data packing into generated IDs)
2. As a side-effect of number one, min alphabet length can decrease from 5 to 3
3. Decrease blocklist-related re-generation attempts from almost-unlimited to the length of the alphabet (cc @tzvetkoff)
4. As a result of number three, re-generated IDs don't have to grow in length (try blocking "SrIu" in the playground to see what I'm talking about)
5. Also as a result of number three, min length padding is smoother now (cc @joviczarko)
6. Sounds like minValue and maxValue are not that useful, let's remove? (cc @peterhellberg)
7. Increase min length limit from alphabet-length to an arbitrary value (1_000 for example)

Pros:

• Less code; spec (with comments, etc) went from 336 to 301
• Limited (but still sufficient it seems) number of re-generation attempts, as opposed to currently almost-unlimited / less-predictable
• Smoother blocklist and min length handling
• Packing more data into IDs + smaller alphabet allowed

Cons:

• More dev work for maintainers to re-adjust code (you + me)
• IDs change, which means users that might have current libs in production would have breaking prod changes (although most of our libs are pre-production version (v0.x) ...so comes with the territory)

Unknowns:

• Are there any use-cases we don't test for since changing reserved chars from 3 to 1?

Current: https://sqids.org/playground (algorithm code / explanation)
Proposed: https://sqids.org/playground/simpler (algorithm code / explanation)

P.S: Also worth noting that I have no intention of changing the algorithm over and over; I figured this might be cleaner + address some current issues/questions, while we're still technically mostly pre-prod.

Thoughts/feedback?

cc @laserpants @vinkla @niieani @antimon2

I am in the process of implementing a T-SQL port of the algorithm so I have some understanding of the algorithm. I am a bit surprised that the algorithm is considered insecure. It is a semetric encryption algorithm and the keyspace is the factorial of the length of the alphabet. This is definitely sufficiently large.

Of course, it is very much vulnerable to plain text attacks - especially if small consecutive numbers are encoded, like the ids in a master table. The minimum length feature will not mitigate this.

But if the encoded numbers are sufficiently large and the plaintext is not known to the attacker... I don't see any issue. Could you explain why you consider the algorithm insecure?

(I admit the above ifs are pretty big in real life use cases but I was wondering about the algorithm.)

Sqids has been ported to Zig here with a minimal test suite.
I will refactor it into a proper package, but it's already functional as is.
Would the Sqids stewardship be willing to create a sqids/sqids-zig repository to host it?

I have created an implementation in Pascal. It works with both Free Pascal and Delphi and includes unit tests for both. Could you please make a sqids-pascal repo? I will then fork it and create a pull request.

Wouldn't it have been better to just continue Hashids (the algorithm) just under the new name and organization?!

The so-called improvements that the new algorithm provides don't in the least seem worth breaking backwards-compatibility over, sure, the code might be slightly shorter and better looking, but that's hardly relevant at all to the end user. Backwards-compatibility, however, absolutely is.

The new algorithm also apparently doesn't accept a salt like Hashids, so the user has no choice but to shuffle the the alphabet manually, which is work that they didn't have to do in the previous implementation. How this is considered an "improvement" is beyond me...

There is really no advantage to the new algorithm from the user's POV. Please seriously reconsider this decision.

Yes, the new name is better as it gets rid of the connotations of the word "hash" and the unification of all the implementations in different languages under the same organization is certainly a good thing, but the breaking compatibility with the old algorithm which is arguably the most important thing when it comes to a library like this, is genuinely unacceptable. It makes no sense. And "use it for new projects" is not a good argument, this makes people lose significant trust in this whole project, and that is not trivial, the decision to use Hashids/Sqids is essentially permenant, so trust, reliability, and future-proofness are extremely important.

Don't do this.

Hi there, I just noticed something:
When no min length is specified:

const sqids = new Sqids({
    alphabet: '3SO4VRHEP8K0W1NJMCBT6DYA79Q2ZIG5UXFL',
});

console.log(sqids.encode([0, 1000]));
console.log(sqids.encode([0, 1001]));
console.log(sqids.encode([1, 1]));
console.log(sqids.encode([1, 2]));

The result:

P4X75
VIYB0
FHQ5
ZDT5

Now, if you set minLength to 5, this will be the result:

P4X75
VIYB0
L428TX
FS856C

Why did the last two suddenly jump to 6 characters?! That seems unnecessary given that they were just encoded with 4 characters, why does specifying the minLength cause Sqids to add 2 more characters, rather than 1, which would've been sufficient to meet the min-length requirement?

This doesn't actually make sense, correct me if I'm wrong but it seems like some sort of a bug.
It can be especially undesirable since usually the point of setting a min length is aesthetic uniformity, which this particular quirk basically defeats.

Would be good to have some kind of versioning for the specification. This would allow implementations to specify which version they are compliant with.

Not sure if this is the right place to post this but sqids-dotnet v2 has just been released which added support for all integral numeric types in .NET (e.g. int, long, etc.) — previously we only supported int.
This resulted in an API breaking change where the SqidsEncoder class now requires the user to specify a type argument upon instantiation; so, all three code snippets on the website need to be updated:

-  var sqids = new SqidsEncoder(...
+  var sqids = new SqidsEncoder<int>(...

Hi @4kimov, as I was building sqids-dotnet a number of questions popped into my mind which I'd figured I ask here (the first one is the most important one):

1.

It seems like in the new algorithm, any string that contains valid characters (valid meaning characters that are found in the alphabet) will always be decoded into some number; I tried feeding the decode function random strings and it gave me a result every time.

This looks like a crucial point of difference compared to the old Hashids, which was not like this. This means that in Sqids, any given number effectively has multiple valid encoded representations. I'm not sure if this was also technically true of Hashids but in Sqids it's far more extreme and apparent, since basically any string you give it, it always yields a number.

So, my question is: Was this somehow intentional? Or was it merely a side-effect of the simplification of the algorithm?

This can be problematic. In the context of a web app, for instance, where these IDs are typically used as part of the URL to identify a resource, this practically means that multiple different URLs can point to the same resource, which results in URL duplication and is virtually always undesirable. For example — with the default Sqids options:

• 2fs is decoded as 3168
• OSc is also decoded as 3168

So, if you have a product, say, with the ID 3168, you'll have more than one URL that points to it:

• https://example/product/2fs
• https://example/product/OSc

This is not good. Have you thought this through?

2.

Why does the min-length have to be less than the length of the alphabet? Characters are allowed to repeat in IDs, right? I'm probably missing something, but I'm not sure I understand the logic behind this particular limitation here:

3.

In the decode function, wouldn't it make sense to add another if clause like the one below that returns an empty array if the input ID contains fewer characters than minLength?

Are there plans to add the ability to encode uuid or hex? It is not always possible to have a numeric PK.