keygen-go VS base32768

Why would you want to scroll horizontally? Or are you referring to the code samples? It's only a code "sample" (i.e. non-working just to show off the platform), so fingerprint would likely come from something like https://github.com/denisbrodbeck/machineid. Full examples are available in the Go SDK docs [^0].

[^0]: https://github.com/keygen-sh/keygen-go

I run https://keygen.sh by myself. I built it about 7 years ago and started running it on the side. I went full-time on it in 2020 when it got too big to run on the side. As for trends -- the market is a bit slower these days due to the current economic environment. I've noticed smaller businesses have had a tougher time buying (and staying on), while enterprises have had an uptick.

Working on adding “environments” to my business’ API (https://keygen.sh). I’ve gone over 6 years without offering a “sandbox” environment to customers, so I’m excited to finally be working on this one. It’s been quite complex implementatiom-wise, and has touched a lot of surface area, since I want it to support multiple named environments (e.g. staging, dev, one-offs isolated test envs for CI/CD). But it’ll be worth it.

Check out https://github.com/keygen-sh/keygen-go. Has auto-upgrade support for Go apps.

qntm did a fun project of using larger bases, constrained to subsets of unicode instead of ASCII like base64. It's specifically for social channels where you're constrained by the number of code points, but not bytes, so you want to maximize data per code point. base2048 is pretty impressive, and base32768 is just absurd.

base32768 is ideal for storing binary data in localStorage with an efficiency of 94%.

A similar thing is actually practical in JavaScript which mandates that all strings are UTF-16. You can cram more data into strings in memory if you use base-327168 encoding, and it serializes to equally compact JSON.