# Thoughts on Project Gemini

2025-06-25 5:14PM -0700

No, not Google's Gemini. Project Gemini:
=> https://geminiprotocol.net/

I saw someone mention it on Mastodon this week. I hadn't heard of it, and went down the rabbit hole of learning about it and playing around with some clients for it. There are two main parts.

First, there is the Gemini network protocol, which docs say "can be thought of as an incremental improvement over Gopher rather than a stripped down HTTP". 

Then there's the Gemini hypertext format, called "gemtext". It's like Markdown, but even more minimalist. That makes it very easy to read, write, and parse.

## Parts I Like

=> https://geminiprotocol.net/docs/faq.gmi
> The "native content type" of Gemini (analogous to HTML for HTTP(S)) never requires additional network transactions (there are no inline images, external stylesheets, fonts or scripts, no iframes, etc.). This allows for quick browsing even on slow connections and for full awareness of and control over which hosts connections are made to. The native content type is also strictly a document, with no facility for scripting […]

This is great! So much of the modern web is a bloated mess of JavaScript that requires multiple round trips to the server just to render a simple page. That's fine if you want to develop an application, or execute intrusive trackers within a user's browser, but it's not a great experience for users, especially on slow devices.

This simplicity carries over to the site design as well. Without styling and inline links, adding navigation to every page would be quite heavy. Instead, you just use your browser's back button.

I also really like a lot of the philosophy behind the design:
* Protecting user privacy
* Protecting user attention and time (no popups, ad videos/sounds, etc.)
* Simplifying things which have become overly complex.

## But Why A Separate Protocol?

The FAQ tries to answer this:

> 7.9 Why not just use a subset of HTTP and HTML?
> […]
> The problem is that deciding upon a strictly limited subset of HTTP and HTML, [would not] create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it.

Except, it's *also* impossible to know in advance what's on the other side of a gemini:// URL! The one header that the Gemini protocol does support is equivalent to HTTP's Content-Type. There's nothing that says it has to be text/gemini. So there's nothing that stops a gemini server from serving an HTML file full of embedded images, popups, and JavaScript trackers that report your viewing habits to third-party sites (whether over HTTP or gemini).

It's the fact that Gemini *clients* don't implement this that protects you from that. At which point, you could just write a Gemini client that reads gemtext over HTTP.

The FAQ continues:

> Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.

I beg to differ! You don't write a client that "ignores unwanted features", you just don't implement them! And since most programming languages already have multiple HTTP client library implementations, it's much easier to just use one of those, fetch some gemtext and render it as you wish.

## Middle Ground

If you would have to write a client to access the gemini:// protocol, and it's the *client* that protects you from the behavior you don't like, then I see no reason not to just write a client that can read gemtext via HTTP.

But, while I'm not sold on the protocol, I like the gemtext format.

So, my plan is to use gemtext, but stick with HTTP. If you `curl` this document, you'll get back its canonical representation, text/gemini. But if you load it in a browser that only accepts HTML, it'll be rendered as HTML. Those that want to use a gemtext-only client can, and those with a much more common HTML browser aren't blocked from reading the content.