💾 Archived View for mozz.us › journal › 2019-08-07_gemini_initial_thoughts.gmi captured on 2023-04-26 at 13:18:43. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

My initial thoughts on Gemini

Published 2019-08-07

I had a lot of fun writing this server over the past few days. My implementation was based on the preliminary spec document here:

gopher://zaibatsu.circumlunar.space/0/~solderpunk/gemini/spec-spec.txt

I have not had a chance to read most of the other discussions yet, so I'm coming into this with a "clean slate".

TLS

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 standards emerge.

Requests

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 hacks.

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 with gopher:

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 the file.

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.

Host: www.example.com

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.

text/gemini

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 things.

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 formatted.

Final thoughts

That's all I've got for now, thanks for the awesome protocol!