This reminds me of how the student meal subsidies are implemented in Slovenia, and in my opinion it was quite unwieldy. You call a phone number and place your phone's earpiece on another device with a microphone. Then, some personal data is transmitted using (ultra?)sound. I remember it being quite unreliable, but that might be down to using the telephone network as the data carrier.
This looks neat, but I don't really understand how it works. I imagine that the DNS record is pointed towards the VPS, and the VPS just forwards all traffic to the actual server via wireguard?
The implementation of the __cos kernel in Musl is actually quite elegant. After reducing the input to the range [-pi/4, pi/4], it just applies the best degree-14 polynomial for approximating the cosine on this interval. It turns out that this suffices for having an error that is less than the machine precision. The coefficients of this polynomial can be computed with the Remez algorithm, but even truncating the Chebyshev expansion is going to yield much better results than any of the methods proposed by the author.
As for the last point, you are right, they are purposefully sending encrypted/encoded(?) data to your phone, which is then sent to their server. The raw spectrum will only be returned from the server if you have an even more expensive "researcher" account...
Is it just me, or running programs under PTVS slows them down by quite a bit? Even when I turn off debugging, it still seems to be slower than when I run the program from the terminal.
I would guess that it is very unsuitable, since for anything but the most trivial models, even those 'Python' libraries resort to highly-optimized (compiled) C subroutines, especially for the training part. Even then you require a highly nontrivial amount of time to train the network, especially if you are working with medium to large datasets.
Later on, when the speed is not so critical, you can do inference with those pretrained weights and your model implemented in Javascript.