Hacker News Reader

Comment by simonebrunozzi | Hacker News Reader

From [0]:

> What Gemini is doing, is saying “we don’t need no videos, images, stylesheets, nor JavaScripts, because we want to have a lightweight web experience, so we throw all that crap out!”. Fine, sounds great. But why does it require a new protocol for that? Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?

[0]: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...

View on HN

You can absolutely include links to media (images, audio, video) in a Gemini document if you want. You just have to download them to view them. Some clients will render them inline when you click on them.

> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?

- So Google/Microsoft doesn't ruin it.

- So you don't need to rely on huge applications basically emulating operating system functionality at this point with millions of LOC and opportunities for vulnerabilities just to publish some text or links.

- So you don't need to really rely on any application at all. `openssl s_connect` will get Gemini pages in a text file just fine if/as needed.

- Gemini's line format is easy to parse for scripts.

>- So Google/Microsoft doesn't ruin it.

Google/Microsoft/etc are already shifting away from the web as we know it to HTTP/3. Once their money making properties are all QUIC/udp based it won't be long before they start depreciating tcp HTTP/1.1 support "for security" reasons. And from a megacorp/institutional/for-profit point of view that makes perfect sense.

>So you don't need to really rely on any application at all. So you don't need to rely on huge applications. Gemini's line format is easy to parse for scripts.

HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.

I really enjoy gemini because it is its own little world. It is the feeling of surfing the www in the 90's again. Everything is rendered the way I want it to be rendered, in whatever client I feel like using. Anyone can code their own client or server without much effort (I'm told).

It does not have to have immeasurably broader support or use standard protocols. Gemini's protocol is orders of magnitude simpler than any version of HTTP ever was and gemtext is far simpler than any version of HTML. Not everyone has to like it. Installing a gemini client is such a low barrier anyway for those that want to try one.

> HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.

So ... because TCP-based HTTP/1.1 might be deprecated on major browsers in the future ... then it's great that Gemini has it's own browsers (optional), application-level protocol, and port, and that it doesn't currently depend on existing HTTP infrastructure?

I am a bit invested in Gemini on the Elixir side and am writing a few tools for it.

some comments

- Gemini don't want to fix the Web, it wants to be something else entirely

- Gemini is deadly simple, so simple that anybody with basic programming skills can write a client for it or a server. Even if nobody will use them, it's still a good exercise and you can implement the full standard not a limited subset of dubious usefulness because basically no web site will render correctly

- Gemini makes search engines an affordable problem space again

- Gemini is not trackable client side, but not necessarily ad free, just a different kinds of unobtrusive ads (I sketched some ideas)

- Gemini is very old school, it doesn't allow anything that's modern and flashy and that's its atrentgh, a subset of HTML will always be rendered on the usual big 3 browsers, it takes too much discipline to not abuse of it

- the protocol is what makes Gemini independent, by the virtue of not being subject to any external "standard committee" 100% controlled by the usual suspects

- Gemini is not cool, and that's great for some like me

> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?

"Just use HTTP" is something I've thought about, and the idea does have merit. Python includes an HTTP server, so for getting a site up in less than a minute, it's a thought.

I'm not sure how easy it is for a browser to recognise and render new content type. I imagine it's quite difficult.

I guess I have something in mind like "gopher, but fixed".

You can serve text/gemini over HTTP, although it is rare (I have only seen it once). (I have a old version of Firefox that I was able to customize so that it can display text/gemini files, both remotely over HTTP(S), and local files (including inside of ZIP archives).

HTTP is messy, but does have some helpful features, such as the "Content-Length" response header (if it is known; it might not always be known but if it is then it would be helpful to include it), and range requests.

I also have idea how you could serve files in any format and be able to specify a response header to interpret it (and/or linking to alternative representations, perhaps using the existing "Link" header) if the client software does not already have that capability. (The end user should also be able to configure their own interpreters, which override those specified by the server, if any.) In this way, you can use Gemini files, as well as various picture formats, audio/video codecs, etc.

Reply on news.ycombinator.com