The Gemini protocol seen by this HTTP client person

Markdown is not a well-defined standard and is arguably no easier to parse than basic HTML 1.0. HTML can easily be rendered as text in a style not dissimilar to raw markdown if required.

The decision to enforce the use of TLS means that rolling your own client is less trivial than had it been optional. It also cuts out a big chunk of the hobbyist market who are most likely to be interested in a small, lightweight protocol. Support for Gemini will therefore be limited to systems with maintained TLS libraries. At the end of the day, anyone sniffing your Gemini traffic is going to be able to see the host you’re accessing - whilst TLS will preventable them knowing which specific page you’re reading, they will be aware of the set of pages you could be reading.

Instead, I am focussing my attention on building small, light web-pages that have completely optional CSS, are pure HTML without cookies or JavaScript and work in browsers modern or ancient. There’s a plethora of great browsers that can access it, from Lynx and Netscape running on a Solaris 8 machine to Chrome on my work PC. Servers are ample and well-tested.

And a good chunk of my website is text (rendered in Groff) to boot.

It’s 95% of the Gemini experience with 5% of the effort and 1000% more reach.

Daniel is not saying that is a wrong thing. He is saying that he has a PR to review and would need a clearer spec for this and gives his opinion on how it can be improved. His opinion is interesting because he is a long time spec user and writer.

One commenter says that it's like the coca cola boss criticizing a competitor, but curl implements a lot of protocols. He probably doesn't care.

It's for fun, granted, but if you want curl to implement your fun project, part of the fun becomes doing things properly. If you bothered writing a spec, it might as well be unambiguous, no? Not that I think the point of Gemini is to be fun, mind you. I think it's a strongly political movement advocating for minimalism. I do believe it's a worthy cause.

His point is also to criticize the technical choices but that's fair game too. Again, his opinions as someone who has a lot of experience in the field are interesting too. Should I implement such a protocol now, I would definitely get back to this article to make sure I'm paying attention to the right things and making the right tradeoffs for my use case.

I overall think the Gemini community should take Daniel's input as a good contribution to their ecosystem. He took time to sit down and consider Gemini seriously. Several times.

Now he finds gemtext pages ugly, it's his opinion expressed on his personal blog, it's not particularly interesting and this opinion is not particularly related to his expertise. It's also not worth discussing with logical arguments since it's taste. Now there's still a point that can be made from this: if many people find Gemini ugly, including someone used to deal with RFCs daily, that means it will stay small. And that it's in the end, not an adequate answer for widespread minimalism it could have been and which is a goal that seems worth pursuing.

Sure, people want unambiguous specs. However there is a list of literally dozens of working clients, servers, and libraries that were implemented based on the Gemini spec as is. Perhaps Daniels concerns are, in practice, not as important?

https://github.com/kr1sp1n/awesome-gemini#clients

I would also point out the hell that is the HTTP/1.0 and HTTP/1.1 specs, and that it took ~15 years for the HTTPbis group to remove all the contrary and ambiguous parts of it. This had little impact on the raise of HTTP

> His point is also to criticize the technical choices but that's fair game too.

Sure, but many of his criticisms are false. Full Stop. (servers and clients DO support TLS resumption. Proxying does work and there are multiple working examples, client's do server certificate validation)

Or don't make sense ("Gemini closes a TLS connection after each request? HTTP figured out keeps-alives in 1996! This is bad design." HTTP has different access patterns. If Gemini had those access patterns it would be bad design. It doesn't)

https://gmi.skyjake.fi/lagrange/