Thoughts on Gemini
tropf
ABSTRACT
I think we have to severly transform the
world wide web, and I don't think Gemini is the
way to do that.
1. Preliminaries
1.1. The Problem with the WWW
The world wide web currently is a mix of different,
very complicated standards. A lot of its features are un-
necessary and even harmful.
This complexity, after the downfall of mozilla, has
lead to Google with chromium, or more precisely, the blink
engine deciding alone how the web is viewed and displayed.
Which in turn leads to further problems, ultimately moving
the power to shape the world wide web away from its citi-
zens.
> There are far more problems with the world wide
web.
1.2. Gemini
Gemini is a stan-
dard and a text format (text/gemini) to solve a proper sub-
set of problems that the web solves, yet being much simpler.
2. Faulty Design Principles
Gemini, according to its FAQ , is designed with
simplicity, privacy and generality in mind. Those are goals
that every engineer should strive for, imho. Though it
seems like those are followed more like a religion, and less
like guiding ideas that have their shortcomings clearly ad-
dressed and considered.
Also it feels like there are more subtle core ideas
that are not spelled out as such, like an aversion towards
applications on the (or for that matter, any) web or the
5 December 2020
-2-
strong focus on operators rather than users.
2.1. Target Audience
Gemini is clearly targeted at programmers, or at least
a technical community.
I think this is a mistake: The information-centric,
fast and privacy-preserving web that Gemini would create has
a benefit to a much larger group of people. As engineers we
should strive for solutions that help all people, not just
ourselves.
This is not just a "religous belief" which I just com-
plained about, but a concept for bilateral good: The engi-
neers of the 90s may have built the web, but a much more di-
verse community of the 00s filled it with content.
I don't think that there shouldn't be techie only solu-
tions; I am a strong proponent of the shell, vim and alike;
but those have alternatives with a lower barrier of entry
(e.g. Notepad or Libreoffice), and they are the backbone of
many people's work everyday. Gemini is not.
2.2. The Meaning of "Simplicity"
Gemini understands simplicity as "can be implemented by
one person over one weekend". I understand that as a
(quasi-) "Hackathon".
Instead of defining simplicity by an absolute measure,
I'd call something "simple" if it achieves much by doing
little.
> The termin "Design" is often defined in exactly
the same way,
The point is that the former asks "What can we
achieve?" first, while the latter puts "What do we actually
need?" in focus--which is the more important question.
3. Missing Features
3.1. text/gemini
The text/gemini format is extraordinarily simple. Too
simple, as it misses features to meaningfully express con-
tent.
3.1.1. Inline Images
As far as I read the mailinglist, it seems that most
users see this as an advantage. I don't.
5 December 2020
-3-
Images are one of the most powerful ways to present in-
formation, much faster and better than text.
Of course, one could argue that you could just link to
an image from text/gemini. But unarguably that makes navi-
gating much more complicated, too complicated in my opinion.
And that's not even considering reading text and viewing an
image simultaneously.
3.1.2. Tables
If you can't use images, use tables. If you browse
around my other articles you'll see that I love using ta-
bles. They are simple to create, simple to understand and
much better than a wall of text. And Gemini does not have
them.
3.1.3. Font Styles
Gemini misses font styles. While I don't care about
the font family used, I can't understand why you'd like to
miss out on such a simple features as emphasis.
3.2. The Protocol
There are technologies that are tried and tested for
Gemini-like applications, yet they are not employed. One
could claim "simplicity" but I don't think that counts, as
the benefits provided clearly outweigh the complexity intro-
duced imho.
3.2.1. Compression
Gemini transfers text. Text is one of the best re-
searched type of content and can be compressed very well,
often by over 50%.
3.2.2. Keepalive
Gemini mandates a new connection for each document
served. As the typical "browsing" of documents involves
many connections to the same server I don't see why not to
reuse the already established connection. Sure, signalling
EOF but keeping the connection open is not trivial but not
unsolvable either.
The problem lies in the cost of establishing a connec-
tion. Gemini (practically) involves both a TCP as well as a
TLS handshake. This can take up to 3 RTTs (plain
TCP+TLSv1.2), to then serve a couple of kilobytes in the
worst case which takes an additional RTT. Of course, using
TLSv1.3 and TCP Fast Open the overhead can be reduced to a
single RTT, but both are far from the norm.
5 December 2020
-4-
3.2.3. Sessions
Gemini does not have sessions. Except it does: It is
trivial to include a kind of session cookie in the url. In
fact, I already used a similar mechanism to avoid using
cookies on the web already.
In my opinion Gemini should embrace sessions and add a
possibility to provide a session cookie by the client. This
way, the client would control the session. Now the servers
can (and will) do some non-standardized tinkering to imple-
ment sessions and we have the problem of the world wide web
all over again.
4. Creating Content
I think creating content for Gemini is too difficult.
You can either write in text/gemini straight away and you
can't use the features of other formats (and therefore not
really reuse your content elsewhere) or you can use some
other, better suited format but then fail to be presented in
all clients.
Currently, the tools to transform content from and to
text/gemini are not available. While I think they will make
creating content easier, they won't be able to solve this
problem.
5. Meta
5.1. Designing a Protocol
I really like the approach of the IETF to designing
protocols: There are mailinglists to discuss and working
groups to decide. At the same time, anyone can publish
drafts and RFCs at any time.
This way there is room for discussion and a way to find
a consensus, while not needing dictatorial power yet provid-
ing the individual with plenty of freedom. To not use this
infrastructure--both in terms of hardware, software and or-
ganizational infrastructure, but also the concepts behind
those--is a bad idea.
5.2. Important new Features
Gemini introduces a lot of new features that are very
welcome and, imo, needed urgently. Among those a step away
from password based authentication, a focus on content and
less on representation and none on client-side-scripting or
a concept to meaningfully use self-signed-certificates.
But one has to acknowledge that all these new ideas au-
tomatically make a wide adoption less likely. Considering
5 December 2020
-5-
that, I don't understand why those new, difficult-to-imple-
ment ideas have to be mixed with a horrible usability.
5.3. What does Gemini want to be?
Most of my criticism here revolves around the question
what gemini wants to be. I think that vision has not been
clearly expressed yet and I hope it will in the future.
Currently I see Gemini as a sort of hope for all those crit-
ical of the current web, while it can't possibly fullfill
all these hopes.
I'd welcome the protocol undergoing some serious recon-
sideration. Also I think that text/gemini should stay, but
be complemented by a more complex alternative, maybe simply
Markdown.
5 December 2020