Whenever Gemini is mentioned here in HN people will ask: "Why not a subset of HTML with HTTP" or some similar "Why not $SOME_OTHER_TECH" question. Which for me is the same as hearing "Why not chocolate cake?" after saying "I like strawberry tarts".
What people don't realise is that Gemini is a different thing for each person involved with the ecosystem. Some people are in it because it is easy to implement, something that can't be said about the recent specs of HTTP/HTML specs. Others enjoy having a spec that is easy to understand and absorb, even if they're not developing with it. There are those that like how clients decide how to present the content, and that some clients allow for a ton of customisation thus placing the user in control of the presentation. Each person is enjoying the ecosystem for their own reason, and that doesn't need to be a reason that serves as an answer to "why not HTML and HTTP?"
Mostly, people do Gemini stuff because they're having fun, and that is enough.
Lagrange is a great client. There are a gazilion others. Pick one up for a ride, have fun.
> 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
AFAIK, Gemini is the protocol and Gemtext are one of the types of documents. Be aware that you can transfer HTML documents over Gemini, and that many clients render more than just Gemtext. My own little client Fafi, built with Racket, can render Gemtext, images, RSS, and Markdown. If you attempt to transfer using HTTP such as having an HTTP link in a Gemtext, it will simply launch the default browser instead. I believe some clients will actually render the HTML in a webview.
Precisely, how many people are really interested Gemini because it's an HTTP like protocol over TLS+TCP instead of HTTP over TLS+TCP? It seems gemtext files are the real draw and those would be a lot less hassle to just do over HTTPS in the first place (for both browsers and custom applications).
But who knows, maybe all of the people hyped about Gemeni are just really excited about TOFU or something and just happen to not be interested in actually hosting non gemtext documents by sheer chance. More likely it seems it's more a form of gatekeeping than anything about the protocol of document format itself. It's almost like if programmers decided .md files should only be served and rendered to markdown clients over an HTTP-like markdown protocol - yeah, it'll keep less programmers looking at it but there is nothing special that couldn't have been done by serving the .md over HTTPS outside the "cool kids club" portion.
In practice it's mostly just programmers, so yeah that's what it mostly is. Gatekeeping to keep the "normies" out. There's nothing wrong with that but I wish the community were more honest about it.
You are wrong. It is "Why not chocolate cake?" after saying "I made strawberry tarts". And you can answer "I like strawberry tarts" as a reply. It is a perfectly valid answer.
People have the rights to do something for fun, and shouldn't be uncomfortable to say it out loud.
A HTML subset allowing client-side choice of presentation to the extent of Gemini would not even allow nested divs for layout, or top header bars (static or floating). It's a spartan choice that even most static blogs don't supply by default. IMO the ability for a client to render a page beautifully without page-supplied styling is essential (reader mode is a pile of heuristics they often fail), but pages do get monotonous and sites indistinguishable, with no server styling whatsoever.
What people don't realise is that Gemini is a different thing for each person involved with the ecosystem. Some people are in it because it is easy to implement, something that can't be said about the recent specs of HTTP/HTML specs. Others enjoy having a spec that is easy to understand and absorb, even if they're not developing with it. There are those that like how clients decide how to present the content, and that some clients allow for a ton of customisation thus placing the user in control of the presentation. Each person is enjoying the ecosystem for their own reason, and that doesn't need to be a reason that serves as an answer to "why not HTML and HTTP?"
Mostly, people do Gemini stuff because they're having fun, and that is enough.
Lagrange is a great client. There are a gazilion others. Pick one up for a ride, have fun.