Added blocklist constant

[vinkla]

No description provided.

[schodemeiss]

Ignorant question and happy to be wrong, but wont a blocklist such as this potentially cause BC breaks by just adding in new words?

For example, lets say that "ABCD" is allowed in v1.0.0. In v1.0.1 "ABCD" is now blocked, any ID's that used to work, now wouldn't. Or worse, where 123 may have generated "ABCD", now generates something different.

If we treat the alphabet as a "seed" -- adding a blocklist essentially adds another part to that seed. But in this case, the blocklist is being driven by the library and is likely to change. Which is different to the default alphabet, because that's been stable since version 1 of hash-ids.

[4kimov]

@schodemeiss It's a good question, and you're right: there is a good chance that modifying the library's default blocklist will make encode function produce different IDs whenever a blocked match is found (it should be expected). Although decoding old and new IDs will still work.

I don't really have a solution for that. The only thing I can think of is doing a major version bump whenever updating the blocklist (so end users will explicitly "agree" to the changes). Another thing we should probably do is add a "notes" section to individual READMEs where we talk about these "gotchas".

Do you have any other suggestions?