The Gemini Protocol in 2026: growing, but still not setting the Internet aflame
Note
This article is about Gemini, the HTTP-like Internet protocol for document browsing, and not the large language model or the cryptocurrency of the same name. Nor it is about astrology.
About five years ago I posted my views on the relatively-new Gemini protocol. Gemini was (and still is) a simple protocol for client-server document retrieval, somewhat akin to the ancient Gopher protocol, but with some more modern features. Gemini’s designers planned for it to be of interest to academics and enthusiasts, and completely incapable of commercial exploitation. We – academics and enthusiasts – made the web; it’s galling to see it wrested from us to sell even more pointless consumer tat that nobody needs, and trashing everybody’s privacy as it does.
The Gemini protocol is, essentially, inextensible; even if it had wide uptake, there’s no realistic way it could be used for tracking users or delivering targeted advertising. It’s unlikely that Google, et al., would take much interest.
The Gemini protocol is an interesting way to try to carve out some corner of the Internet for non-commercial use – in use a bit like the regular world-wide web, but without all the advertising, spyware, and AI slop. A “small web”, as it’s sometimes called. I don’t think anybody expected a huge uptake, but we did expect (well, hope) that those who did adopt it would have something interesting to publish. Gemini has a high technical barrier to entry so, in practice, almost all content on it was, and still is, the work of nerds. It isn’t all technical, but there’s an undeniably nerdy flavour even to the non-technical content. As an unabashed nerd myself, I find this entirely satisfactory.
Back in 2020 I wasn’t convinced that Gemini was going to be the solution to any of the problems affecting the world-wide web, and I’m still not. I felt that making TLS encryption mandatory was a mistake, as it would exclude retrocomputing and minimal computing enthusiasts, who might otherwise have been easily won over. The default ‘Gemtext’ document format was, I believed, too inexpressive to be fun to work with, or to read. In particular, there was no easy way to convert any other widely-used document format, not even something as simple as Markdown, to Gemtext.
There was also, at that time, a dearth of decent, graphical clients for Linux. I got around this problem by writing my own client, JGemini.
What’s improved in the last five years?
On the positive side, Gemini adoption has risen considerably. From a few hundred capsules (sites) in 2020, the count has risen to at least six thousand. And it’s worth keeping in mind that these are mostly hand-crafted sites, maintained by enthusiasts – not the LLM-generated rubbish that increasingly plagues the regular web. There’s some interesting content there, if you can be bothered to search for it.
Also, new clients have become available since 2020. I’m using Lagrange which supports not only Gemini, but a number of newer, similar protocols, which I’ll discuss later. Lagrange is a splendid, cross-platform client, with a graphical interface and sophisticated typography – it makes reading a pleasure. It certainly beats my half-hearted efforts to write a client.
While a number of Gemini-based services have come on-line since 2020 – news aggregators, search engines, bulletin boards – it isn’t all good news on this front – more later.
What hasn’t improved?
First, and most importantly, the two most-criticised weaknesses of Gemini have not been addressed. The protocol still requires TLS, which still excludes people who might otherwise have been enthusiastic. It may not be obvious in a world where TLS is so widespread, but it’s a fabulously complex and resource-intensive method of encryption. Moreover, it’s by no means the only game in town, if you’re designing a new protocol from scratch. Worse, most Gemini capsules don’t benefit from encryption at all – for these it’s just a needless hurdle.
In addition, the impoverished Gemtext document format hasn’t changed. It still provides no means to emphasize text, or to put hyperlinks in line with text. It still requires each paragraph to be written as a single, long line.
The reason the founders of Gemini chose this rudimentary format, I believe, was to make it easy to implement clients. Fair enough: Gemtext is, at least, easy to parse, and easy to display. Still, it’s irritating to write, and quite tedious to convert from anything else.
The subject of the document format has been discussed repeatedly on various forums. It’s often been proposed to make the default document something more like Mardown. To some extent, the maintainers of Gemini clients were open to the idea: Markdown isn’t particularly hard to parse. Frankly, Markdown would be readable if displayed to the user as-is.
There was also a proposal to allow the use of ANSI terminal escapes in Gemtext documents. This would have made it easy to change the colour and emphasis of text, among other things. I didn’t entirely approve of this plan. It would be easy to implement in a console-based client; in fact, on Linux it would be self-implementing, since the display logic is already present in the console. But for a graphical application, or for application other than for Linux, it would have been a nuisance.
Nevertheless, a number of clients did provide preliminary support for this proposal, and it could be seen to work. But this idea, along with most suggestions to improve Gemini, have been shot down – politely, but implacably. I guess the hard core of Gemini enthusiasts are happy with it as it is.
That leaves other potential converts to “small web” protocols to try to live with Gemini with its faults, or create alternative implementations – more on this later.
A second problem, unchanged from 2020, is the ephemeral nature of
Gemini-baed online services. It’s perfectly possible to create a search
engine for Gemini, for example, but these things come and go. Right now,
my favourite is Kenedy (at gemini://kennedy.gemi.dev/).
However, its operator says:
“Kennedy runs on an Late 2014 Mac mini…”
This, again, is a service that we may not be able to rely on in the long term. Of course, others may come along – the problem is finding them.
Other services have come and gone, too. There was at one time a Gemini-based online encyclopedia called “gemipedia”. That, too, seems to have gone, and I have no idea whether it will be coming back. There are news aggregators, bulletin boards, and all sort of other useful things – but it’s hard to be sure they’ll still be there tomorrow. Any listing of Gemini-related services you might find will be out of date within a few weeks. That, for better or worse, is a consequence of the hobbyist nature of Gemini.
Third, and related to the previous point: so far as I know, nobody is offering commercial Gemini hosting, with virtual hosting support. Since the Gemini community remains small, it’s currently not difficult to get space on somebody else’s server. However, the lack of virtual hosting makes it difficult to use this space effectively, for any long-term application.
I can’t, for example, get my own domain name, and have it resolve to a specific content directory on a shared server. This is the way that all commercial web hosts work. It’s not that Gemini servers don’t support this – some do. Rather, it seems that nobody’s actually set one up in a way that makes it widely available.
This lack of virtual hosting means that some of the proposed Gemini extensions won’t work very well. For example, there’s a draft specification for adding a “favicon” to Gemini capsules, that will behave similarly to the way they work on regular websites. But, lacking proper virtual hosting, it will only be possible to set a favicon for the entire server, however many capsules are using it.
These things aren’t limitations of the Gemini protocol, nor of the clients and servers that support it. Rather, they are indicative of the relatively slow update of Gemini, such that nobody is doing large-scale, commercial-grade hosting.
What new problems have come to light?
One of the things we’v noticed since 2020 is that authentication is somewhat fiddly. To be fair, Gemini was never really intended for the kind of web-based application that needs authentication, but even a simple bulletin-board service requires a way to tell one user from another.
Since Gemini depends on TLS, it’s always possible to use client certificates for authentication, should it be necessary. Unfortunately, creating client certificates for multiple services is a nuisance. Clients like Lagrange can do it automatically, but that still leaves the problems of securing and backing up the certificates. A User/password combination is something that you can simply remember, but a TLS certificate needs to be stored.
It’s been possible to use TLS client certificates for authentication on the regular web for decades, but it’s noteworthy that, outside of business-to-business operations, nobody actually does. It’s still mostly user/password, or the nightmares of OAuth2 and multi-factor authentication where security really matters.
The biggest new problem, though, is that Gemini’s weaknesses have allowed the “Small Web” community to fracture, spreading the already-limited resources even more thinly.
Gemini alternatives
The limitations in Gemini I’ve mentioned have led to enthusiasts spawning alternative projects. Spartan, for example, is much like Gemini, but without the encryption. Unfortunately, it still mandates the same Gemtext document format as Gemini. And, without even the option for encryption, it’s never going to be suitable for any application that requires security or privacy.
Scorpion is another simple Gemini-like protocol, designed to handle both encrypted and unencrypted traffic on the same port. It does this by using the first byte of the client’s request to determine whether to encrypt or not. Using encryption is therefore the client user’s choice.
In principle, this gets us the best of both worlds: users that require security can have it, but plaintext communication remains possible.
For better or worse, Scorpion has a rather odd, binary document format. It’s true that this format addresses some of the limitations of Gemtext: it supports simple formatting like bold and italic, and it also allows changes of character encoding in the body of the document. It does both these things, while not making the document any harder to parse, by dividing the document into binary blocks with type and length headers. Each block can specify a particular format, or a particular encoding.
Unfortunately there are no editing tools for the Scorpion format (so far as I know), so the best that can be done is to convert some other document format (e.g., Markdown or HTML). But if that’s the case, why not use Markdown or HTML in the first place?
Some new protocols are radically simpler than Gemini, even than
Spartan. I have a fondness for Nightfall
Express, or nex. This protocol is unencrypted, and
returns plain text data in a pre-formatted layout for use with a
fixed-pitch font. That is, the author gets to create the layout exactly
as it will be seen by the viewer.
The problem with nex document formatting should be
obvious: we no longer live in a world of 80x25 terminals. I don’t know
whether nex documents could be properly formatted for a
portrait display, such as on a smartphone. Still, it’s very
easy to author documents for nex.
The problem with all these alternatives is that they have a small uptake, even compared with Gemini, which itself is hardly setting the world on fire. So far as I can see, there are about twenty servers hosting Spartan worldwide. Of course, it’s early days, and uptake of these alternative protocols might increase. In the meantime, the small community with a interest in this kind of technology is being split into smaller and smaller groups.
So what to do?
I like the idea of Gemini, although I’m not entirely happy with its implementation. When I first came across it, I decided to wait, to see if something better came along, before getting too invested in it.
Sadly, it’s not clear to me that anything better has come along, and I’m not sure it’s going to. All the alternatives being proposed have weaknesses of their own. It seems more sensible to me, at the present time, to support Gemini, flaws and alls, than to propose yet another protocol, and potentially fracture the user base even further.
So I’m starting to convert some of the articles on this website to Gemini format. I’ll be adding some new articles that won’t be appearing here, either because they’re not related to my professional interests, or because they’re just not safe for work. There’s no prospect that my Gemini capsule will ever be as large as my main website, but I want to have some content on Gemini, just to help out a bit.
You can find my Gemini capsule at gemini://gemini.ctrl-c.club/~lars_the_bear/. My thanks go to the folks at Ctrl-C Club for hosting this.
I’ll continue to monitor the situation, anyway, and see how Gemini and the others develop.
Closing remarks
I really want Gemini (or something like it) to succeed. While it’s growing, a rise of ~5000 capsules in five years isn’t all that encouraging. There surely must be more people out there who want what Gemini offers; in fact, I know there are. I don’t think the “small web” is ever going to be more than a nerdy hobby, but there are plenty of nerds in the world.
I like to hope that there’s some sort of critical mass; that, when the user base gets large enough, Gemini will just snowball. I don’t think that fixing what I perceive to be its technical limitations will be enough: people need to start using it in earnest. In my small way, I plan to do that; I hope others will do the same.
