On the Shortcomings of Gemini Protocol | Hacker News Reader

On the Shortcomings of Gemini Protocol

lof.flounder.online

70 pointsurlwolf46 comments

> then AFAICT there's no way to tell that the server is done sending the file."

This is incorrect. See https://gemini.circumlunar.space/docs/specification.html section 4:

As per RFCs 5246 and 8446, Gemini servers MUST send a TLS `close_notify` prior to closing the connection after sending a complete response. This is essential to disambiguate completed responses from responses closed prematurely due to network error or attack.

> There is no version number in the protocol, and the response layout was carefully constructed to make extending it hard

I think if you want HTTP, you should use HTTP.

I don’t believe this addresses the point: the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished loading yet or is potentially infinite/undesireably large/hung instead of temporarily paused.

You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Sending payload sizes upfront (when available) is generally a great idea.

> the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished or is potentially infinite/undesireably large/hung instead of temporarily paused.

Of course it does. The client receives close_notify and they know the stream is complete. If they don't get it, it wasn't. Simples.

You're thinking of HTTP which does have this limitation (if not using an extension like chunked-transfer, multipart, or more popularly: TLS/https).

> You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years.

Nonsense.

> Sending payload sizes upfront (when available) is generally a great idea.

There are lots of great ideas out there, but if you implement all of them you get the Homer-mobile. Do not let yourself worry so much about the goodness of the idea and instead think about what you get and how much it costs:

Requiring fixed-length payloads would cost you streaming, whilst making them optional means you have to write both code to support them and code that tolerates their absence -- back where you started.

To know whether or not it would be worth it you'd need to ask the Gemini users.

> hasn’t finished loading yet or is potentially infinite/undesireably large/hung

For the case of a hung connection, is there any great cost to a client just keeping the connection open indefinitely? We’re talking a few kilobytes of memory? The user will surely close the client before it matters.

I can see some value in signalling the content length in order to allow a client to display a progress bar for a large download. But I can totally live without that in exchange for a simpler design.

I love the idea behind Gemini but the people central to the project act like jack**es anytime you suggest something.

First time I saw Gemini on HN I got so excited and I emailed them and posted on the thread; I then subscribed to their email list server. The discussion there was along the lines of “yeah the discussion on HN was positive but just a bunch of feature requests from people ignorant of our tribal knowledge and we don’t like so meh”.

It would be much more productive if they were engaging and gently instructive, eg “that’s an interesting idea and we thought about it but ultimately we decided that it wasn’t aligned with our project; here’s a link to the email archive discussion”.

But instead they are completely dismissive.

Sure they’re free to act that way, but it is just self marginalization as people will stop trying to engage with them and ignore the project.

Two of the core ideas of Gemini are that it should have as few features as possible and that it should change as little as possible.

Gemini is not very popular, but it is quite mature—there are a number of clients and servers and users who expect Gemini to not change. In this sense, Gemini is more mature and more resistant to change than the web.

If you proposed adding a feature which would require changing clients or servers, as your first message on the mailing list, you probably got a response that ‘you don’t understand Gemini.’

Gemini isn’t looking for more people to suggest changes to the spec. If you’d like to create a Gemlog or write a client or a server, I hope that the Gemini community response is more polite.

Agreed - it feels a bit like people get overly dogmatic about things at times.

My view is that if they don't accept change (and to be fair there is some change - albeit minor - in the spec from time to time) then they risk browsers implementing their own things outside of the spec, and you end up with an internet explorer situation where there are non-standard things that everyone uses but which are not part of the spec

A couple of examples is favicons and inline images - not in the spec but which a few clients and browsers support, but others don't. People will continue to find new and creative ways to squeeze in new things.

If they are not flexible and open to change where it is legitimate and makes a positive impact, but instead act as some sort of holier-than-thou cabal where outsiders are shunned as they "don't get" Gemini etc, then they run the risk of the protocol getting out of control, or only ever being used by the few dozens of people who are true believers in the original spec being the only possible way. I am not saying let's open the floodgates to any and all features anyone can dream up, but things like tables seems like a legitimate feature that would add quite some value to Gemini's users.

There also seems to be this odd view that clients must be super simple to implement (e.g. no tables, no inline-images, no inline-links etc), yet on the other hand they are asking clients to do a lot of TLS gymnastics with e.g. per URL client certificates and TOFU handling etc (enough that there are accompanying docs to the spec explaining the concepts etc to help client implementors get it right).

Feels kinda hypercritical to me to insist on simplicity on one hand (and indeed justify decisions based on this requirement for simplicity), yet requiring quite some considerable complexity on the other. It is not like inline-links is anywhere even close to the devel-in-the-details level of code complexity required to handle TOFU databases of host certificates and allowing users to select individual client certificates for each request made etc.

> If they are not flexible and open to change where it is legitimate and makes a positive impact, but instead act as some sort of holier-than-thou cabal where outsiders are shunned as they "don't get" Gemini

One of the main goals of Gemini is to have an immutable spec. The goal is to never add features. So yeah, the Gemini community is a little tired of people proposing changes and features to add to the spec. And I think it’s fair to say at some point that you “don’t get Gemini” if your first message to the mailing list is a request to add features.

To address the favicon point—the spec explicitly disallows making more than one request to open a page. Favicons require a second request, and therefore are not compatible with Gemini. The Gemini community has had the conversation about favicons and decided they didn’t want them. AFAIK no browser supports them by default. Now what?

To the TLS point, someone in Geminispace very recently proposed removing TLS citing the same arguments you did. There were dozens of Gemini posts made going back and forth, but on the whole the demand wasn’t there and we’re going to continue to use TLS.

Gemini’s simplicity makes it super easy to criticize aspects of the design or suggest new features. So it gets boring. I could go find thousands of words on why Gemini doesn’t have TLS. But it wouldn’t be a better explanation that the one on the Gemini home page, which I assume that you’ve read and are unhappy with.

I have no issue with TLS in Gemini, just that it is pretty hypocritical in my mind to cite simplicity as a driving factor, but then use a complex-to-implement TLS system.

Anyway I think you have missed my point - it is not about what the "immutable spec" says, but the risk that people go their own way and do their own things with Gemini. Favicons is one thing and may be "solved", but there will be more in the future that people will add, e.g. you are already seeing abuse of the preformated block and it's alt-tag to embed markdown content and tables "illegally". I guess the all-powerful immutable spec won't be able to be updated to handle that though. Oh well.

I don’t think there is anything stopping you from making Gemini v2? Just write out a new spec.

It’ll be just like markdown.

"Web only for documents, not apps" appeals to me. However, it's not a question of just shaving off features. Some features of the web are extraneous for that purpose, and some are missing. For example, rendering maths on the web portably still requires you to make your page into an app. The defaults (wrt fonts e.g.) are poor. And while I'm at fonts and maths, you can't assume the client has fonts appropriate for displaying maths, so now you need to bundle fonts with your page. The automatic hyphenation algorithm used in browsers is also visibly inferior to the one used in LaTeX.

And Gemini solves none of that. Maths is even harder with Gemini than with the web.

Indeed. Gemini aims to be a text-first protocol. It doesn’t attempt to nor purport to be a general-purpose document transfer protocol. (Although you can transfer a PDF or LaTeX document over Gemini, most clients will simply download these files.)

Scientists don't need tables implemented in their markup. They need tables inside linked files that readers can actually use in data analysis without having to learn yet another complex technology. The browser could render linked CSV or SQLite files in a nice table widget for instance and people interested in the data could open it up in R and not have to mess around with parsing XML.

Having a browser that can natively “render” a SQLite file is actually an amazing idea. Some default table-like representation along with a cli would be killer.

That sounds like a feature I'd disable (especially if it were something that a browser would try to do without prompting) just because of the odds it'd end up causing major security issues, either because of how it got implemented by the browser manufacturer or due to SQLite itself. I'd personally rather just download the file and handle it outside of my browser. Support for PDF files is bad enough as it is.

It wouldn't be safe with SQLite, it's not designed to be run in a sandbox

Are you sure? I see inline benchmark summary tables in every published paper I read.

I think for that it's somewhat less critical, since it's a somewhat less common usecase to take this whole benchmark table and somehow continue data analysis on that.

But for things like atomic data or various model setups that you do want to use in your code/your work that's based on the previous paper, having a machine-readable version is a huge time-saver.

Pandas is actually quite decent at extracting tables from HTML.

https://pandas.pydata.org/docs/reference/api/pandas.read_htm...

Regarding this:

  what it also doesn't have is a way to say when the file has ended

Is this not the stated purpose of TLS close-notify as described in the gemini specification? [1] Given that it follows a one-request per connection, this is a good signal for end-of-file, no?

  As per RFCs 5246 and 8446, Gemini servers MUST send a TLS `close_notify` prior to closing the connection after sending a complete response. This is essential to disambiguate completed responses from responses closed prematurely due to network error or attack.

[1] Section 4: https://gemini.circumlunar.space/docs/specification.gmi

I just discovered Gemini a few days ago. I really was taken aback by the idea of no version number in the protocol. I kept reading, and tried out the 100ish line Python client, then the Lagrange client. It all gives me a nice fuzzy feeling.

I'm on a different quest, to create a Memex as originally envisioned. I'll likely set up my own capsule and blog about things there, in parallel with my old blogspot blog.

I discovered Gemini about a week ago, too. The couple of clients I first tried didn't work. Someone suggested Lagrange, which is a very nice client. Bombadillo is pretty good, too, if you just want to work from the command line. I think I just got unlucky with my initial tries.

I've started my own server, and may put it on a separate machine for extra security.

A site that everyone should check out is Antenna: gemini://warmedal.se/~antenna/ which is a blog aggregator.

Another nice one is Exploration Surprise: gemini://tilde.team/~sumpygump/explore/ It shows three random domains a day. So you can have a lucky dip.

Why Gemini? Because it's just so cool. It has a little bit of a sub-cultural feel to it. A big difference between Gemini and the regular internet is that people write because there is something they want to say.

I went onto Tumblr just to see what would happen. The first thing that popped up was an annoying window that wanted me to sign up. I clicked on "Maybe Later" instead. Apart from being an annoyance, there's a subtle cue there, isn't there? We'll get you later.

So, the first post that popped up was a picture of a pizza. Why, exactly? Like, what is it the poster is trying to communicate here?

Scroll down a little bit and there's a post by a guy who seems to have an eating disorder. He mixed peanuts with coca cola. That was essentially his whole schtick. Um, OK.

Scroll down a little bit further and I get a pop-up saying "We know you were really enjoying yourself, but we're going to need a little more info." Need? You "need" more info about me, do you?

This is why I like Gemini. There's a whole different mindset. People aren't trying to sell you stuff, scrape your analytics, or be superficial "influencers."

I've recently more or less ended my Gemini journey

<gemini://gerikson.com/gemlog/gemini-sux/Winding-down.gmi>

I think it's great the community still has buzz, and that it's probably still growing, but it's not for me.

There's nothing inherent in HTML that leads to vapid "influencer" culture. If you host your own server, you're basically doing what Gemini is doing now, but with almost infinitely more flexibility. It's just that people did that in 2005 and it's "old".

Proving your point, the Kineto proxy turning that into HTTPS + HTML:

https://gemini.envs.net/x/gerikson.com/gemlog/gemini-sux/Win...

Kineto is written by the same person who wrote Gemini (Drew DeVault), showing us that Gemini as a protocol isn't really needed for transport to share Gemini content, which can be just plain HTML anyways.

Drew DeVault didn't write Gemini. He merely participates or participated in the community.

My mistake there, I meant "the Gemini server" meaning to refer to https://sr.ht/~sircmpwn/gmnisrv/ which I'm to understand is pretty popular. Bad English on my part, apologies.

Yep, no problem. Thanks for correcting!

Elaho client on iOS.

Before I learned about Gemini I was already 80% done writing my own protocol. I finished it for the most part. It's a little different in that it's designed for people to make keyboard navigable TUI's. Such is life.

Here's some info on it with some gif demos. http://uggly.bytester.net

Oh, a memex (aka zettelkasten). That's a perfect match for the format. I have > 5000 notes and would love to publish at least a fraction. And they are not about tech, which I think would be refreshing for the atom aggregators (which are quite a bit biased towards tech, in particular simple tech).

I use lagrange too. It makes gemini pages very pretty to look at with very little effort. Take that, medium. We just need a few top bloggers to take up the medium.

Memex is NOT zettelkasten.

Memex is Vannevar Bush's 1945 vision[1] for a tool that helps people in the way they work. It's human first, relying on machines to adapt to users. It's literally called "As We May Think"

Zettelkasten is a way for force people into certain ways of working an organising their thoughts. It's the opposite of the vision of Memex, and while some might find it useful don't let it pollute the beautiful original vision.

[1] https://www.theatlantic.com/magazine/archive/1945/07/as-we-m...

Before criticizing Gemini one should read the mailing list archives. I haven't heard an objection yet that wasn't raised and addressed already, typically months and months ago. You might not like Gemini, but it's unlikely that you've got an original reason for it.

- - - -

I think of Gemini as like the Haiku form for poems: yes it's highly restrictive, but the art is just in expressing yourself though the form.

People coming around and protesting that haikus aren't sonnets, or that they aren't suitable for writing plays, are missing the point, IMO.

These aren't valid criticisms of Gemini and seem to be front end webby complaints. No wonder "flounder" doesn't want to reveal the identity of his or her likely non-stem soft science friend. Perhaps the friend is entirely made up.

What bums me the most is that I can’t wrap gemtext at my desired line length. I hate having to write “long lines” in my editor and prefer ‘gqip’ing them to 72 (that’s Vim for hard wrapping selected text). Terrible choice.

Gemini also has some issues with inline language changes if I remember correctly, which has some accessibility implications.

----

TLDR I think that Gemini has a lot more in common with platforms like PICO-8 than with other HTML replacements. It's a niche community, and that makes me a lot more charitable towards "nothing should change and we don't care enough to address X technical concern" takes than I used to be.

----

The thing that makes Gemini popular is also the thing that makes it easy to criticize: the spec doesn't evolve and it's not really seeing a ton of development, on purpose.

In other contexts, small concerns are something that would just get addressed later, but with Gemini they will never get addressed, so you kind of have to decide upfront whether or not you care about those concerns, because they're never going away. On one hand, this makes Gemini great for some things (getting into client development, not needing to worry about the platform changing underneath you) and really bad for other things (being a general-purpose format for more than just hobby/niche communities).

But to be fair (and despite how it gets characterized), I don't actually believe that Gemini is trying to be anything other than a stable platform for niche communication, and I don't mean that as an insult. It's pretty obviously not trying to be the future of the web for normal people or a universal way that people write text online, or even a universal "light" format for communication, and while I do have criticisms of the protocol, I also don't think that it has any real obligation to be the future of the web.

When weighed against some of the other proposals people have made to "simplify" the modern web (Amp, PDFs, Canvas, etc...), Gemini is noticeably better and noticeably more accessible, and actually has a real community of people using it. So it wins on all of those fronts. It's just if you want it to be anything more than that, you're going to be disappointed, because Gemini is deliberately designed not to be reactive to any needs that its authors didn't already think about, which is pretty much game-over for wide adoption or longevity as a useful spec in the mainstream.

When people don't understand that, it leads to fighting over "is this feature actually important for a text-only web, do people really need this?" But in my mind that's the wrong way to think about Gemini's downsides. There are many features that are important for a text-only web that Gemini doesn't support because Gemini is not a foundation to replace HTML, and it's less about whether Gemini supports every feature that would be good or even necessary for it to support if it was used in the mainstream, and more about whether it supports just enough features to be usable for a generally nice, semi-closed community. Most proposals beyond that turn out to be just bikeshedding.

It's a little weird, but if you think of Gemini as more of a Tumblr/Twitter alternative and less as an Amp competitor, then a lot of the refusal to evolve or address new concerns start to make a lot more sense. If you're building a general-purpose text-based document format, then you have to care about things that Gemini doesn't care about, and you can't take an attitude of "people's needs matter less than keeping the spec small." But despite what the official website says, I don't think that's what Gemini actually is, and understanding that has made me feel a lot more charitable about the protocol than I used to be.

----

I will completely hypocritically say though that I do still think they should fix the `lang` problem since that's just a general accessibility feature and is arguably the same or even less complexity than specifying languages in the header. But, hey, that's just me proposing another spec change. :)

Why would a scientist need to publish images and plots on the web? Just write a blog post which is basically an abstract of your article and then simply put a link to a gorgeous PDF containing the full article filled with gorgeous visualizations.

So you are using pdf to handle the fact that gemini is useless.

Or you could use http and have it all perfect on your website.

could you please explain to me then what the purpose if the web is? to do everything?

I'm not sure if it's web's purpose, but yes, it does everything. You can read, work, play games, watch tv, listen to music, all on the web. It is actually quite impressive.

you are implicitly arguing for browsers to become operating systems

Browsers are an app platform. That has been true for a decade now. They don’t exist to manage hardware, only to expose everything as nice and standardised apis.

I couldn't even display my papers abstract on Gemini if I wanted because I can't include formulas.

And I can't resort to "hard coding" formulas as SVGs as inline images are not allowed.

You can put images links in fine, between lines. Stick your svgs in and publish.

The lack of any form of typeface styling makes even basic citations clunky in Gemini.

Visualizations inline in text documents have been a staple of any written media, since... the beginning?

The web was pretty much invented just so people don't need to use PDFs

Reply on news.ycombinator.com