Gemini TLS Client-Server compatibility

I've set up this capsule just a few days ago and already I am dealing with first technological absurdity. One would (naively) expect that with protocol as simple Gemini, compatibility between clients and servers would be a given. A non-issue!

That's not the case. I've noticed log of Gemini server (Agate) is full of errors like:

"TLS error" error:peer is incompatible: no overlapping sigschemes

or

"TLS error" error:unexpected error: incompatible signing key

After a bit of digging, I've found that this is caused by the fact that I have used "too fancy" signature scheme when generating the certificate.

I have (naively) assumed that in the year 2023 every modern operating system supports Ed25519. OpenSSH supports it since fucking 2014.

Hahaha, no. Turns out that especially mobile Gemini clients are problematic in this regard (and one well known proxy).

Agate author is aware of this issue and has made ECDSA the default algorithm for certificate generation some time ago. It's just me who has naively used Ed25519, seeing such option present.

GitHub issue

GitHub PR related to this issue

Nevertheless, I had to make a decision - what do to with this cluster fuck. I came up with a few options.

• Do nothing about it. Fuck the mobile and proxy users and leave it as-is. They are not hardcore enough to care about them anyway. Though, I can't be sure that it's only mobile and proxy users who are affected. Obviously, some desktop clients may also have old/broken TLS libraries.
• Reduce the security of already inherently insecure protocol by not using Ed25519 keys. In theory it would be as simple as deleting the keys, then removing the --ed25519 option from the server arguments, therefore making Agate fall back to ECDSA. But then I would break TLS for everyone who already visited the site, since they have trusted they key on first use. This is just stupid. I knew that TOFU was a dumb idea, but decided to try Gemini anyway, hoping that simplicity will outweigh any problems caused by it.
• Just go back to HTTPS, with a simple statically generated site. Tempting, but not elitist enough.
• Maybe serve content over the Spartan protocol instead of Gemini. Who needs TLS when it's broken by TOFU anyway? At least Spartan does not create false pretenses of security.

Tired with this mental exercise, for now I decided to choose the first option - do nothing about it.