The Anukari website is now functionally complete, at least for the bare bones features that will be needed to start doing some early pre-alpha testing. There are still a number of details that I'd like to work out before stopping work on it and getting back to the VST code itself, but not a lot.

The APIs that the VST code will use to authorize the full version of the software are complete. The authorization is extremely simple: the VST sends a machine fingerprint along with the license key, and the API server checks that the license key is real, has remaining machine slots, and then signs the machine fingerprint and sends it back. I'm not doing anything to make this all hard to crack, but am simply adding a "lock on the front door." It will be a sign of success when someone kicks it in (cracks the software).

The web GUI for the user to manage their license keys (which mostly amounts to deleting machine IDs that they're no longer using, to free up quota for new machine IDs) works. I have an admin dashboard to create license keys in batches.

After I finish cleaning up the web stuff, the next thing I'll do is work on the c++ code to add the GUI that actually lets the user enter a license key, and makes the API requests to get the signed authorization. After that... I can start a pre-alpha basically anytime I want. 😉

I told myself I was going to take the day off from work today, but then I wanted to just finish one tiny little thing on the website auth... and here I am 6 hours later with auth kind of working.

I am sad to see that the state of web auth libraries is basically the same as it was 12 years ago, the last time I set up auth for a website. In fact in some ways it was more of a PITA this time, because the next-auth.js folks are up on their high horse about not using credentialed (email/password) logins, and trying to get everyone to just use oath2 providers. Which is a super annoying position, because when I run into a website that only does oath2, I leave. So clearly there's at least 1 user out there that hates this.

Anyway, because of their moral stance, the next-auth.js folks seem to have actively tried to make credentialed auth difficult, and the docs are terrible. But it is all still possible, obviously, and finally I've figured out how it is supposed to work. I now have a MongoDB instance running with basic user registration / login, though granted the visual style is atrocious at the moment.

But auth is probably the biggest hurdle to having product registration, so this is good progress. Now it's just a matter of creating the APIs and db tables for product registration, and then creating the simple UI to manage license activations (e.g. delete the license on your old windows laptop that exploded so you can install on a new one). This should go pretty quickly, I think.

I burned the first half of the day reviewing a bunch of legal stuff that I need for the business -- the EULA, privacy policy, website terms, etc. This has to be the least exciting part of the whole project, and as much as I'd like to just skip it, if there's any chance that the product will be even moderately successful I really do need this stuff. Fortunately, the lawyer I hired specializes in small tech businesses, so he understood what I am doing super-quickly. Hopefully in another week or so I'll have final documents and won't have to use any further brain cells on legal matters.

Code-wise, I finally just got fed up with boost::numeric::interval and wrote my own. The frustrating thing is that I started with my own Interval class, and when I saw there was a Boost one I figured, "why not use it?" I needed a few of the handy methods it had (hull, median, etc) and figured it was a great implementation.

WRONG. The API is fine, but the implementation is vastly over-complex and it is incredibly difficult to understand what conditions it will throw exceptions under. For example, for my PrecisionSlider implementation, an interval where the lower and upper bound are the same (a "singleton") is used to represent a slider that displays a single point, not a range. (Duh.) This works fine most of the time, but some of the GUI fuzz tests were failing under rare/obscure cases where the boost library would throw a "not supposed to be a singleton" exception.

I looked into how to disable that, and what caused it in the first place, and... dear lord the code is horrible. After 10 minutes of noodling on whether I needed the policy "checking_no_nan<>" (which allows nan) or "checking_catch_nan<>" (which throws nan, i.e. the opposite of catching it), I threw the whole library in the incinerator and burned it.

Now I have a 25-line Interval class again that does exactly what I need and can be understood by a 6 year old. Sigh...