Don't enforce HTTPS for the /api/ paths

[vladkorotnev]

Hello!

I would like to make use of your API in an embedded microcontroller project, and I'm sure many other DIY hobbyists would love to as well.

However HTTPS is a very heavy and unnecessary burden to run in an embedded setting, and brings little use anyway since there are no authorized endpoints anyway.

If you could please consider lifting the HTTPS requirement and making the API (or at least the /get endpoint) available over HTTP as well, that would be much appreciated!!

[Feridinha]

@vladkorotnev Why don't you use a very simple proxy for that?

[vladkorotnev]

If a device can access an external service directly, it must do so directly, simple engineering rules.

Imagine I did set up a proxy — now I don't only have to pay for parts to build the device, but also for a server on a monthly basis. Maybe I would have donated that money to keep the collective effort of lrclib running, but now I pay for a useless proxy instead.

OK, then imagine I did go that route anyway, and then give the device I built to my family and a few friends, and they enjoy it. But then I die the day after, and nobody pays for that proxy server anymore — so now the device is a bunch of useless e-waste instead of a cherished memory for them.

Then you can say, oh, but you can use someone else's proxy. Sure, I could do that. The next year they die — and now I need to figure out how to patch that out from my firmware (because who knows if it even compiles at that point) and use a different one, if that even exists. Or even worse, they start replacing the API responses with the one for Never Gonna Give You Up all the time — they have much more incentive and control to do that kind of thing rather than a hypothetical ISP with an unencrypted connection.

Plus the presence of encryption in a microcontroller context doesn't really matter anyway, because most of the time you're so tight on memory (and cannot ship an update once the thing is built and given to someone else), that instead of keeping a proper key store you'd be accepting any certificate presented, so there is no security to begin with — the potential MITM organizer can just present a self-signed certificate. So in the end it's just a waste of memory on an enormously oversized TLS library in the firmware (which isn't also very reliable, duh) that is used only for a single API.

I'm not even going to mention the potential environmental impact of all the useless encryption and decryption we do today, because without proper measurements it would just sound like greenwashing marketing crap (plus, modern day hardware encryption is pretty efficient).

Just to clarify, I'm not saying stop offering HTTPS — I'm saying please offer the option of not having to use HTTPS.

I'm not sure about how this specific instance is running, but if it's nginx, then it's literally one line of config — to open the API and relieve the pain in the ass for all arduino hobbyists (or vintage computer enthusiasts or less wealthy ones — I know some people who still have to use a Windows 2000 computer for daily tasks!). A lot of other APIs that don't have authorization or sensitive info offer this option — and it's just a bit of etiquette that costs nothing to implement, but helps your guests massively.