| > If you bothered writing a spec, it might as well be unambiguous, no? 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) |
And the spec is the only realistic thing to build on, because clients diverging from the spec have been threatened by blacklisting by other users (Amfora attempting to use emoji "favicons" for example led Drew Devault to threaten to ban the client from accessing his servers).