> Which for me is the same as hearing "Why not chocolate cake?" after saying "I like strawberry tarts".
Desserts don't have network effects. The global hypertext network that we call the World Wide Web is a great achievement. Yes, commercialization has led to some awful excesses. But the Web still lets us all create the kinds of spaces we want, without needing to create separate networks that only a relatively few techies can access. That's why I think Gemini is misguided.
You can read my response to this at virgo://example.com/response567. It's not any harder to access you'll just have to close your current app and load one of the many Virgo apps (plenty on mobile too!) to read it.
In all seriousness Gemini (the protocol) is really no easier to implement than a subset HTTPS client as both are basically HTTP type commands over a TLS channel. Heck HTTP isn't even the hard part anyways, for everyone worked up about it I wonder how many wrote their own TLS implementation. Anayways don't conflate "every feature and function of a web browser" with "things an HTTPS client has to support" as even "Every HTTPS feature" is out of scope for most clients. When it comes to actually rendering Gemini (the document format) the difficulty doesn't change based on what protocol delivered the document.
Plus everyone already has tooling out their ass for HTTPS from viewers to libraries to debug tools to servers to command line clients to proxies to anything else you'd ever need. Plenty of these existing tools don't even care about the documents being transported, you're free to download a .md over HTTPS via wget hosted on a Caddy server even though nothing in that entire chain has a clue what .md is or should look like. These tools span from running on tiny microcontrollers to abstract high level user facing import functions in apps so it can clearly scale to any use case where you can render to a screen.
Wait until you read about HTTP upgrade mechanisms, HTTP transfer encodings or even 206 Partial Content implementations that are broken everywhere.
HTTP 0.9 was easy to implement, but everything starting from 1.1 and upwards is borderline insane, especially SPDY and QUIC.
While I don't agree with gemini's design decisions (and neither with gopher's), I can fully understand their point of view in regards to unnecessary complexity and side effects of network states.
Source: Building a peer to peer Web Browser, for around 2 years already (still far away from usable).
As I said just because a web browser may support a lot of things doesn't mean your simple subset client/server has to. I have no doubt implementing HTTP/2, HTTP/3 and its QUIC revisions, SPDY and its revisions, and every extension and option known in the specs would be a lot of work. Not doing so doesn't require making an alternative protocol. You're still free to implement a subset of HTTP/1.1 just like you're free to not implement Javascript or WebGPU when making a simple HTML browser.
You want to TOFU certs? Go ahead, HTTPS isn't going to stop you. You want to use client side certs even though most websites don't? Go ahead, HTTPS supports you. You want to use a custom port? Go ahead, HTTPS supports you. You want to leave some features out? Go ahead, you don't have to implement every feature Chrome supports
Desserts don't have network effects. The global hypertext network that we call the World Wide Web is a great achievement. Yes, commercialization has led to some awful excesses. But the Web still lets us all create the kinds of spaces we want, without needing to create separate networks that only a relatively few techies can access. That's why I think Gemini is misguided.