# My initial thoughts on Gemini
I had a lot of fun writing this server
over the past few days. My
implementation was based on the
preliminary spec document here:
I have not had a chance to read most of
the other discussions yet, so I'm
coming into this with a "clean slate".
I appreciate the simplicity of taking a
stance and requiring TLS to always be
on. It certainly reduces complexity of
having to negotiate the connection type.
I will say that it makes local server
development a bit harder because even
in 2019, generating self-signed
certificates is still a painful process
with openssl. And with TLS connections,
you can't use dumb TCP network tools as
primitive gemini clients. But I suppose
the positives outweigh the negatives.
I do worry about the longevity of the
TLS. Something like UTF-8 will be around
until the end of time, even if the wider
internet starts to adopt other
encodings. But security protocols have
the potential to be phased out
completely from operating systems if new
No complaints here. I like that it's
specifically UTF-8 encoded and not
random bytes. If it were me, I would put
additional restrictions on what the PATH
can contain. These are based on of how
I've observed people using gopher/HTTP:
- Must be a valid UNIX-type file path,
must start with a "/".
- No whitespaces allowed in paths.
- I would discourage adding query
parameters and other CGI oriented
There are several benefits for clients
if the above points are enforced. It
allows clients to implement tree-like
navigation, e.g. "go up one directory",
"view sibling pages". It also makes
scraping and site auto-discovery a lot
simpler and more standardized.
I've done a bunch of hacky stuff with
gopher selectors, mostly just because I
could. I'm sure it pisses off everyone
who tries to scrape my gopherhole. Some
clients, especially gopher->HTTP
proxies, screw up encoding special URL
characters in the path because it's
difficult to get right.
## Response Headers
Love it! Solves two giant deficiencies
1. I can actually return an error code
for a binary / text file. It's so
important to be able to do this
instead of something hacky like
returning a 0 byte response when the
file does not exist.
2. The MIME type for the file is
embedded directly in the response. I
don't need to be redirected from
something like a gopher menu in order
to know what to expect when I load
There are probably dozens of other HTTP
headers that could be argued would add
utility if they were ported over to
gemini. Of course, that's not
constructive since you're not trying to
re-implement HTTP here. I WILL argue for
one header though that I have really
missed when deploying gopher servers.
Vhosts. I want to be able to point two
DNS records to the same machine, and run
multiple servers from the same IP
address. This is only possible if the
client can specify which domain name
they are trying to connect to, so a
reverse proxy can route the request to
the correct server process.
This drives me crazy in gopherland and
I've had to resort to putting different
servers behind different port numbers.
This breaks a fair number of clients
that will only load from port 70,
including the Firefox plugin.
## Response Body
Not much to say about this. I like that
the end of the response is simply
closing the connection. I like that
there's nothing weird going on with
trying to re-use connections.
I despise the gopher menu format. Text
lines starting with "i" and significant
<TAB> characters are both horrible
conventions and make it painful to write
gopher menus by hand. Props to the
proposed format for fixing both of these
Here's what I really think though. My
absolute number one problem with gopher
is that the menus look like crap on
mobile. Servers wrap their lines to
70ish characters on the server side and
it's always way too wide for phone
displays. Reflowing text doesn't work
well because of all the ASCII formatting
people use that depends on monospace
fonts. This is the main roadblock that
stops me from using gopher nearly as
much as I otherwise would.
For this reason alone, I think anything
that provides an avenue for servers to
use monospace fonts and hard line
wrapping should be discouraged. Yes, I
realize that this is hypocritical since
I stuck ASCII art on my own front page.
But that's my point. It's simply too
much fun to use figlets and ASCII
formatting. The only way to stop people
like me from doing it is to make it
impossible to do.
Here's how I would alter text/gemini to
fix this issue:
- Render blocks of text the same way
that "text/markdown" does it. Single
newlines should be converted into
spaces. Two or more consecutive
newlines should mark a new paragraph.
Line wrapping should be done by the
client in the way that looks best for
the display. The server should have no
control over how a block of text is
## Final thoughts
That's all I've got for now, thanks for
the awesome protocol!