Why is there a limit of 70 million unique ARK strings?

[aculich]

In the README you mention: https://github.com/jkunze/docker-arknoid/blob/8e368ace4ef163098cfaeb6fa04920426a5edaf9/README.md?plain=1#L22-L23

Why is 70 million the limit? Where in the code does that limit exist? And is 70M an arbitrary hard-coded limit or is there some other reason you can't do more? And is the number of minters actually unlimited or is there some other hard limit to be aware of, as well?

[jkunze]

I'm thinking of adding a new section: LIMITATIONS In being a simplified interface to the Noid software, this script uses a fixed identifier template. Like any Noid template, the algorithm runs out of identifier strings at a certain point. Newer, unlimited algorithms are under development and will be released to the ARK community, but there are no known plans to fundamentally change either this script or the Noid software.

[aculich]

This SQLite Implementation Limits page is a good example that spells out the limits and why they exist— usually based around a power of two. I'm suspicious of 70 million since it is an oddly round number that lies somewhere between 2^29 and 2^30, so I'm curious how you arrive at the limit and whether or not it has been tested.

When it comes to digital objects at scale, I can very easily imagine hitting 70 million.

[jkunze]

Each minter uses a unique 2-char prefix with the fixed template, "eedeed", where e=extended digit (radix 29) and d=digit (radix 10). When all unique combinations of that 6-char length template are used up, the template does not expand (unlike the newer N2T and EZID algorithms, which auto-expand), so you get 29*29*10*29*29*10 = 70,728,100 strings before the minter is exhausted.

Yes, it's annoying to have to switch minters, and one of the big ARK users has exhausted many Noid minters (with even larger templates) with their many billions of ids. This arknoid tool is not the best choice for heavy industrial application.