I have looked at various criticisms of Gemini, and I have some of my own,
although I also think it does some good things. I have also looked at the
Spartan protocol, which is also good. Below, I quote various sources. I
will also reference my own idea of the alternative protocol, which I have
posted to this newsgroup (although there may be changes to the file since
I have posted it; you can download the latest version from the link
provided in my message (currently HTTP only, unfortunately)).

(Of course there are more criticisms but for now I just wrote what is below.)

> The web has become much more than a protocol for reading documents:
> controls that communicate both ways with the server so that they can be
> also updated in real time is a really useful aspect that won't make them go
> away anytime soon. I rather wonder if the browser is the best interface for
> that, or if html is the best protocol for that use.

I think HTTP and HTML are certainly not the best protocol for that, and
neither is Gemini nor my own one; there are others, e.g. IRC for fast chat
and Telnet for interactive use.

(However, Telnet doesn't have separate URL paths to access different
programs (and cannot transmit the host name); you must use different port
numbers, different IP addresses, or make a menu for the user to select one.
Some other protocols are also limited, and sometimes you might want to make
a different one but still use URLs. For this reason, my own protocol design
has the "I" subprotocol for this purpose.)

> Having links only on their own lines rather than part of text is really a drag

Links as part of text is not as good for being printed out on a paper.

(I have considered in my own format, to have a very restrictive kind of
inline links, although I have decided against it, for simplicity. What I
considered was that the link must be to another part of the same document
and that you cannot specify the text of the link (the client must decide
somehow, e.g. if it is printed out, as "page <number>" or "section
<number>" or similar, or if on screen, as a button that can be clicked).)

> No way to indicate basic formatting in-line in text, such as bold,
> emphasis, underline or code.

In my own design I have decided to have four (and they cannot be combined):
normal, strong, emphasis, fixpitch. Clients are allowed to ignore them,
except that "fixpitch" MUST use fixpitch fonts (although it is OK if all
text uses fixpitch fonts, in which case no special handling is needed).

The exact display of these styles is up to the client (and may be
configurable by the user).

> No way to specify syntax highlighting

This seems to me it is probably unimportant. (I am not entirely sure.)
(Adding it would make it more complicated anyways, probably.)

> No tabular data without resorting to hacks like preformatted blocks

I had considered tabular data in my format, but decided against it for
simplicity. Instead, you can link to another file with the data. (I wanted
to make a simple format that can be used for tabular data; CSV has a few
problems, but maybe TSV will be good.)

(Alternatively, I might change my mind about inline tabular data in future,
perhaps with some discussions about it before being done. However, a
separate file has some advantages; see below.)

> Readable preformatted text cannot be differentiated from artistic content
> like ASCII art, affecting accessibility

It is a valid concern, although results in some complexity.

> No inline images, diagrams, mathematics

I don't want inline images, though. (Nevertheless, it might be helpful for
printed out documents; but even then, you might not have a colour printer.)

I think that to clean the view, and to reduce bandwidth requirement, it is
better to not have inline images; the user must deliberately select them if
they want to view them.

For diagrams (of which there are many different kinds, so it is not simple)
and mathematics, that is a separate issue, but that would still result in
complication, so might be better to be avoided.

> No way to submit long-form content, like a multi-paragraph comment on a blog

For discussions, I think that NNTP would be better anyways, so I think this is
not a very good criticism. However, there are uses where it would be useful to
send using the protocol, such as a wiki, and I have included the "S" subprotocol
in my own specification, for this purpose.

Spartan also has the way to send data, in case you like that.

> No way for a server to indicate the size of a resource until it's all downloaded

This is my issue with Gemini too; I also don't like this feature of Gemini. So,
in my own I allow an optional way to specify the size of a resource. (I also
included range requests; implementation is optional.)

> To repeat, the existence of all these weaknesses is not a failure of
> Gemini. It was never intended to do those things. The challenge for someone
> who is suitably bored or innovative is to look at lists like these, expand
> them a bit, and work out how we could get the results we want without it
> inevitably snowballing into the madness that is arbitrary code execution in
> our browsers, people painting pictures with CSS, WASM, Web Bluetooth, and
> all the rest of it. There is a gaping chasm between Gemini and the modern
> web where something like this could be created.

I agree and am trying to do it (see my other message).

> The reduced complexity however also makes it less visually pleasing to
> users and by taking shortcuts in the protocol, it risks adding complexities
> elsewhere instead.

"Less visually pleasing" is not a problem. Clients can add styles (possibly
subject to user configuration) to use colours, fonts, etc, that the user will
desire; the document need not specify styles (which I think is undesirable
anyways; it is better for doing by the client by the user settings).

However, "risks adding complexities elsewhere instead" is a valid concern.

> There are multiple problems with doing TOFU [...]

I dislike TOFU also. I also think that mandatory TLS is also a problem.

> By insisting on passing on the entire URL in the requests, it is
> primarily a way to solve name based virtual hosting, but it is also easy
> for a Gemini server to act as a proxy for other servers. On purpose. [...]
> Since Gemini is (supposed to be) end-to-end TLS, proxying requests to
> another server is not actually possible while also maintaining security.

Passing the entire URL is good for name based virtual hosting.

Proxying is not mandatory anyways. Of course that is the issue with the
security, but then you would not use it if you need to be secure.

> The spec then goes on to explain that the URL needs be UTF-8 encoded when
sent over the wire, which I find peculiar because a normal RFC 3986 URL is
just a set of plain octets.

I agree that this is a problem. There is no reason for this. The URL should
be ASCII (which is what Spartan says, so it is an improvement).

They say that maybe this is only true of the host name. Well, that would
at least be meaningful, but I still think that it is unnecessary and is
also a bad idea anyways; ASCII only is still better (you can still specify
any host name in purely ASCII, so such a thing will still work).

> There is nothing written about how a client should deal with the existing
> query part in [the text input] situation.

This is why I specified, in my protocol design, that the server MUST NOT
use the 1x response in this case. (If it does anyways, then the result
is unspecified.)

> The protocol enforces closing the connection after every response,
> forcibly making connection reuse impossible. This is terrible for
> performance if you ever want to get more than one resource off a server.

Using a new connection each time is much simpler, though, so it does have
that advantage.

The Gemini file format doesn't load multiple resources at the same time,
so it is not needed to load multiple resources at the same time.

> [Gemini] comes with significant trade-offs for the author, however.
> Compared to standard vanilla HTML4, there are no inline links, no provision
> for media other than text on a page, and the styling of the content is left
> to the client.

I have mentioned reasons above why I believe that these trade-offs are
desirable, however. I agree with Gemini here, and disagree with the criticism.

> I used to be a Gemini enthusiast before it hit me: if this is really a
> content-focused markup language, where the client gets to decide how to
> present the content, then why must I used ASCII art (or worse, a separate
> CSV file) to display an inline table? ASCII tables are terrible for screens
> that are either short or wide, don't have line wrapping, don't have column
> alignment, and have absolutely abysmal accessibility.

It is a valid concern. However, I think that a separate CSV file is better
than using ASCII art rather than worse, although I can also understand the
opposing point of view; it is also valid.

> What if we can re-introduce the plugin system in a safe way? Can a
> hypothetical FireChrome browser VM automatically download a MusicXML
> snippet rendering plugin from my site when a user visits it and ask the
> user if they want to run it (license: GPL, signed by dmbaturin's key, wants
> access to: current page). That's something I'd be happy to use, something
> that gives me and visitors more opportunities, not less.