Here are my thoughts on the author’s closing points. Bear in mind he knows lots about protocols and I know next to nothing about them:
Split the spec into three separate ones: protocol, URL syntax, media type. Expand the protocol parts with more exact syntax descriptions and examples to supplement the English.
I disagree with the suggestion to split the spec. Gemini was made to be accessible to casual coders. I think all the information necessary to do some hacking should live in a single document. A beginner Gemini developer making some quick tools should not have to think about what a URL syntax spec document is and know to refer to it. Expanding the protocol part, though sounds reasonable.
Drop the TOFU idea, it makes for a too weak security story that does not scale and introduces massive complexities for clients.
This seems like a hassle-vs-security tradeoff that the Gemini designers made deliberately. Time may prove that they picked this tradeoff wrong, but it comes with some interesting side effects. One is that it makes Gemini completely unsuitable for e-commerce or serious business, which may actually be a good thing. This by necessity keeps Gemini weird.
Consider a way to re-use connections, even if that means introducing some kind of “chunks” HTTP-style.
Personally I’m not swayed by the “It should be faster” arguments, because Gemini does not need to be fast. It was intended to serve small documents to human beings, who consume them rather slowly. The energy efficiency arguments, though, I do find compelling. It would be nice to see Gemini or some Gemini successor make some optimizations to minimize server energy consumption.
I didn’t track the development of the spec so I have no insight, but I very much took some of those decisions as a deterrent for those you want to keep away (a form of neo-luddism and I don’t mean that as a pejorative). Sad news is that if your capsule becomes popular, you will not (never?) reach the ability to serve your content on the scale of faang shrug
The certificate/tls one does annoy me, because security should be a universal. Since the post was published, I’ve been thinking about the implications of not having the same model as elsewhere with regards to TLS. Aside from the privacy issue which the post points to (are you actually connecting to the genuine destination), the gemini documents don’t really do anything fancy so that’s not really a vector to attack the visitor, but your gemini client is likely linked to libraries which are prone to security issues e.g zlib
Interestingly, Solderpunk’s own AV-98 client lists support for both TOFU & CA certificate validation in feature list. Probably because it rides on the support there in Python’s SSL library.
Here are my thoughts on the author’s closing points. Bear in mind he knows lots about protocols and I know next to nothing about them:
I disagree with the suggestion to split the spec. Gemini was made to be accessible to casual coders. I think all the information necessary to do some hacking should live in a single document. A beginner Gemini developer making some quick tools should not have to think about what a URL syntax spec document is and know to refer to it. Expanding the protocol part, though sounds reasonable.
This seems like a hassle-vs-security tradeoff that the Gemini designers made deliberately. Time may prove that they picked this tradeoff wrong, but it comes with some interesting side effects. One is that it makes Gemini completely unsuitable for e-commerce or serious business, which may actually be a good thing. This by necessity keeps Gemini weird.
Personally I’m not swayed by the “It should be faster” arguments, because Gemini does not need to be fast. It was intended to serve small documents to human beings, who consume them rather slowly. The energy efficiency arguments, though, I do find compelling. It would be nice to see Gemini or some Gemini successor make some optimizations to minimize server energy consumption.
I didn’t track the development of the spec so I have no insight, but I very much took some of those decisions as a deterrent for those you want to keep away (a form of neo-luddism and I don’t mean that as a pejorative). Sad news is that if your capsule becomes popular, you will not (never?) reach the ability to serve your content on the scale of faang shrug
The certificate/tls one does annoy me, because security should be a universal. Since the post was published, I’ve been thinking about the implications of not having the same model as elsewhere with regards to TLS. Aside from the privacy issue which the post points to (are you actually connecting to the genuine destination), the gemini documents don’t really do anything fancy so that’s not really a vector to attack the visitor, but your gemini client is likely linked to libraries which are prone to security issues e.g zlib
Interestingly, Solderpunk’s own AV-98 client lists support for both TOFU & CA certificate validation in feature list. Probably because it rides on the support there in Python’s SSL library.