Obligatory disclaimer: I was the second person, after Solderpunk, to be involved with the Gemini protocol. I implemented the first Gemini server (even before Solderpunk) and I influenced quite a bit of the protocol. Now, with that out of the way ...
TLS. The original idea for Gemini was "a more modern gopher, with TLS" since at that time (2019) people were experimenting with server gopher over TLS [1]. This was also the time of the "Encrypt All The Things!" that Google was pretty much forcing on everyone [2] that Solderpunk decided TLS was mandatory. During the mailing list age [3] there were two distinct groups complaining about TLS: the first group wanted it optional, and a second group wanting to replace TLS with something else, usually a bespoke encryption system the proposer just saw that promised to be simpler/more secure/faster. Of course, only one person in the second group even bothered with implementing their idea, and they later recanted, saying it was probably a bad idea.
Markdown: One could very well use Markdown for Gemini. People seem not to realize that Markdown not only has a MIME type (RFC-7763) but is documented as well (RCC-7764). Since Gemini supports MIME, this is trivial. No client, no my knowledge, handles this.
ANSI escape codes: a bad idea in my opinion. Way too easy to hide text and possibly (at least on MS-DOS/maybe Windows?) to reprogram the keyboard to do bad things. My own simple text client strips any ANSI escape sequences to remove this possibility, but most don't.
Client certificate use: my fault, even if I still think it's a good idea. I'm sad that the use of client certificates never really took off on the web, but key management has always been the hardest part of cryptography. Yes, one can "simply remember a password" but who does these days? Most people use a password manager, which requires storage, much like a client certificate.
Size of Gemini: it's actually larger than gopher.
Another aspect that I think is glossed over is that Solderpunk wanted Gemini to be easy to implement (both the protocol and the document format). In hindsight, I think "ease of implementation" over everything else was a bad idea (and Lagrange, perhaps the most popular Gemini client, itself isn't small, nor easy to implement), but that wasn't apparent at the time. I didn't particularly mind using TLS, but I was using libretls, the library that people should be using for TLS over raw openssl use. As I found out, stuff I found trivial to use (like client certificates) weren't that easy with openssl, but again, that's hindsight.
[3] 2019-2021. The mailing list imploded due to a server crash and it was never restored nor restarted. <editorializing>This was probably for the best, as the community became very toxic towards the very people doing the development.</editorializing>
Markdown not only has a MIME type (RFC-7763) but is documented as well (RCC-7764)
This is misleading. You know why they’re in two RFCs? It’s the same reason why Markdown is unsuitable.
RFC 7763 is basically an admission that Markdown’s not going away, and that we should really have at least some sort of MIME type for it—which should have been done ten or twenty years ago, but the lack of governance around Markdown prevented it. It also includes a couple of other small things in sections 3 and 4. This is the rigid stuff.
RFC 7764 does document Markdown, but not to specify it. It might as well have been called “The Sad Story of Markdown”, for it tells the history and why it’s such a mess and what (with some wishful thinking) you can try to do about it. Followed then by registering a handful of variants.
“Markdown” is a loose family of similar writing formats. It’s unsuitable for direct publication. You need to be specific about what variant you’re using. Though even that probably won’t be enough: you might want something like “CommonMark but without HTML tags” or “CommonMark but with limitations on which HTML tags and attributes are supported, and such-and-such behaviour in case of unpermitted elements”. The whole thing truly is a mess.
Markdown: One could very well use Markdown for Gemini. People seem not to realize that Markdown not only has a MIME type (RFC-7763) but is documented as well (RCC-7764). Since Gemini supports MIME, this is trivial. No client, no my knowledge, handles this.
One could also trivially just do HTML over Gemini. I did it myself with a few tweaks to elinks, just to prove I could.
For whatever it is worth, I have always thought the use of client certificates was one of the most compelling parts of Gemini. I saw them used in a clever ways at least once, and have long felt they are underutilized.
If we're measuring active Gemini sites, I agree there are almost certainly more of them.
If we're measuring absolute resources available, I think this is arguable due to the archival content many of the active Gophers maintain. I see very few of this sort of thing on Gemini.
Not that it really matters much :) but we should be specific on the stats.
There are only around 300 or so known gopher servers running, whereas Gemini has I think low-4 figures. But yes, there are some very large gopher servers in that 300.
One thing I haven't seen mentioned: Gemtext's stripped-down markup isn't just an inconvenience. For some languages it's closer to a fundamental barrier.
Japanese ruby annotations (<ruby> in HTML) exist precisely because there's no other reasonable way to gloss kanji with furigana in running text. This isn't a presentational nicety; it's how you make a text legible to readers who might not know a given character. Traditional Mongolian script runs top-to-bottom, with columns progressing left-to-right. Without something equivalent to CSS writing-mode, the text doesn't render awkwardly, it just can't be rendered correctly at all. Arabic and Hebrew need proper bidirectional text handling; Thai has no word separators, so rendering it correctly requires the kind of line-breaking logic that plain text pipelines tend to quietly ignore; Tibetan and Khmer rely on complex ligature and stacking behaviour that falls apart without thoughtful font and layout support.
HTML's <ruby> element, for what it's worth, came from a real internationalization need. Microsoft introduced it for Internet Explorer 5 specifically because East Asian users needed it, and it eventually made it into the W3C standard. That's not the kind of complexity that crept in because advertisers wanted it. It's the kind that accumulated because the web was, at least sometimes, actually trying to accommodate how people write.
I think the Gemini designers were imagining a hypothetical average writer who uses a Latin alphabet, left to right, with no need for anything beyond ASCII-adjacent text semantics. That's a pretty specific person to design around and call it “simple.” Simplicity that only works for a subset of human writing systems isn't really simplicity. It's just a different set of assumptions made invisible by familiarity.
Even for European-centric authoring, there's basic deficiencies in gemtext. The lack of standardized bold or italic means you can't refer to citations (as in an academic context) etc. in a standard manner.
Latin alphabet, left to right, with no need for anything beyond ASCII-adjacent text semantics
This feels unfair because nothing in the protocol is ASCII specific, documents are UTF-8. Maybe you’re right that someone who is able to communicate in UTF-8 is a western strawperson and that inline HTML support is required for Japanese speakers so that they can include <ruby> elements, but that hardly seems like Gemini’s problem. If you can’t author a coherent text-based document in UTF-8 it seems like you should bring that up with the Unicode consortium.
The encoding/rendering distinction matters here. UTF-8 encoding furigana and kanji is trivial; the question is whether you can express that a run of hiragana is a gloss on a specific kanji, attached to it, rendered above it. That relationship is what <ruby> encodes, and it has no equivalent in plain text. Writing 漢字（かんじ） is a workaround, not the same thing.
The Unicode consortium point is a non-sequitur: Unicode handles codepoints, not layout. Mongolian vertical text, Arabic bidi, Thai word-breaking—these are rendering problems, not encoding problems, and they're not Unicode's jurisdiction.
I'd also gently push back on “hardly seems like Gemini's problem.” That framing accepts the premise: Gemini genuinely can't do these things. My point was that this isn't a neutral technical tradeoff. It's a design choice that happens to be costless for Latin-alphabet writers and fairly significant for others.
I think the problem is that we call Gemini documents “documents.” It short circuits people’s brains. They go, “oh, like LaTeX documents” and then they’re suddenly unable to live without footnotes and inline images and bold and underline and table of contents and mathematical expressions. There was one guy who was working on a project to convert some textbooks to Gemtext, and he got hung up on the lack of inline math support.
But of course, all these same people go and post on Twitter or Facebook and don’t complain about a lack of <ruby> elements or any other HTML element for that matter. Maybe if we just called them “Gemini posts” then people would understand that they’re fundamentally plain-text and just happen to have headers.
The “posts not documents” reframe doesn't really rescue the argument. Gemini's own stated goal is to be a space for publishing content that would otherwise live on the web. If the scope is actually “just posts, like Twitter,” that's a significant step down from the project's own ambitions.
And the Twitter/Facebook comparison works against the point being made. Facebook has invested heavily in internationalization: it handles Arabic and Hebrew bidirectional text, Thai line-breaking, and a range of complex scripts reasonably well precisely because those are real requirements for a platform with a global user base. It's a case where a commercial platform did the work that Gemini's designers opted out of.
The “just call them posts” solution is cosmetic. Renaming the format doesn't change what it can and can't express.
I don't really participate in the Gemini community but I do like the project a lot, and Antenna was pretty much the front page of the internet Gemini for me. It's sad to see it go; I'm worried the ecosystem will split up such that we will no longer have such a single "front page". Still, I hope a worthy replacement will spring up.
However, the experience of using Gemini, especially as it's had some time to grow, is an interesting topic, especially the rough edges that the author has run into, and the alternatives that have sprung up in the years since its introduction.
Gemini is performance art. It shows us how the web can be for some purposes. It shows how something that you can code in a couple of hours can do some stuff better than stuff no one can code (Microsoft gave up on maintaining a browser engine).
One thing I mentioned in IRC the other day that I think is not as well known is the Gemini subscription specification. Instead of RSS, gemtext pages can have an implicit feed by having multiple links with dates in them.
This sounds like something minor, but I think it's not. Nowadays, if you want to write a simple blog, you could do it with very simple tools... except for the RSS feed, which is a pain to write by hand. With Gemini you can create a subscribable blog with... just a text editor without a huge effort.
(My current blog uses this idea- I convert the gemtext to HTML and my converter adds an RSS feed if the gemtext contains an implicit feed.)
(Of course, yesterday I also faced the reality again that I'm slowly drifting apart from RSS feeds. That was not a happy place.)
Third, and related to the previous point: so far as I know, nobody is offering commercial Gemini hosting, with virtual hosting support.
My current setup is also designed to do this. Basically I've configured Apache to do MultiViews, serving both gemtext and HTML, and then my Gemini server is just a dumb proxy that is virtual host-capable. My server is designed to be a tilde, and for instance my ~user website is also served on mydomain.example.com. I would like to "productize" this a bit.
I stick to gopher, although Spartan is interesting.
The TLS and UTF-8 requirements, as well as not being able to query size before fetching, make Gemini too annoying, and as the protocol cannot evolve, it is non-fixable (by design).
spc476 | 16 hours ago
Obligatory disclaimer: I was the second person, after Solderpunk, to be involved with the Gemini protocol. I implemented the first Gemini server (even before Solderpunk) and I influenced quite a bit of the protocol. Now, with that out of the way ...
TLS. The original idea for Gemini was "a more modern gopher, with TLS" since at that time (2019) people were experimenting with server gopher over TLS [1]. This was also the time of the "Encrypt All The Things!" that Google was pretty much forcing on everyone [2] that Solderpunk decided TLS was mandatory. During the mailing list age [3] there were two distinct groups complaining about TLS: the first group wanted it optional, and a second group wanting to replace TLS with something else, usually a bespoke encryption system the proposer just saw that promised to be simpler/more secure/faster. Of course, only one person in the second group even bothered with implementing their idea, and they later recanted, saying it was probably a bad idea.
Markdown: One could very well use Markdown for Gemini. People seem not to realize that Markdown not only has a MIME type (RFC-7763) but is documented as well (RCC-7764). Since Gemini supports MIME, this is trivial. No client, no my knowledge, handles this.
ANSI escape codes: a bad idea in my opinion. Way too easy to hide text and possibly (at least on MS-DOS/maybe Windows?) to reprogram the keyboard to do bad things. My own simple text client strips any ANSI escape sequences to remove this possibility, but most don't.
Client certificate use: my fault, even if I still think it's a good idea. I'm sad that the use of client certificates never really took off on the web, but key management has always been the hardest part of cryptography. Yes, one can "simply remember a password" but who does these days? Most people use a password manager, which requires storage, much like a client certificate.
Size of Gemini: it's actually larger than gopher.
Another aspect that I think is glossed over is that Solderpunk wanted Gemini to be easy to implement (both the protocol and the document format). In hindsight, I think "ease of implementation" over everything else was a bad idea (and Lagrange, perhaps the most popular Gemini client, itself isn't small, nor easy to implement), but that wasn't apparent at the time. I didn't particularly mind using TLS, but I was using
libretls, the library that people should be using for TLS over rawopenssluse. As I found out, stuff I found trivial to use (like client certificates) weren't that easy withopenssl, but again, that's hindsight.[1] I'm not a fan of the approach used to support TLS on gopher and it's difficult to support properly.
[2] By marking non-TLS sites with scary warnings.
[3] 2019-2021. The mailing list imploded due to a server crash and it was never restored nor restarted. <editorializing>This was probably for the best, as the community became very toxic towards the very people doing the development.</editorializing>
chrismorgan | 6 hours ago
This is misleading. You know why they’re in two RFCs? It’s the same reason why Markdown is unsuitable.
RFC 7763 is basically an admission that Markdown’s not going away, and that we should really have at least some sort of MIME type for it—which should have been done ten or twenty years ago, but the lack of governance around Markdown prevented it. It also includes a couple of other small things in sections 3 and 4. This is the rigid stuff.
RFC 7764 does document Markdown, but not to specify it. It might as well have been called “The Sad Story of Markdown”, for it tells the history and why it’s such a mess and what (with some wishful thinking) you can try to do about it. Followed then by registering a handful of variants.
“Markdown” is a loose family of similar writing formats. It’s unsuitable for direct publication. You need to be specific about what variant you’re using. Though even that probably won’t be enough: you might want something like “CommonMark but without HTML tags” or “CommonMark but with limitations on which HTML tags and attributes are supported, and such-and-such behaviour in case of unpermitted elements”. The whole thing truly is a mess.
jfloren | 15 hours ago
One could also trivially just do HTML over Gemini. I did it myself with a few tweaks to elinks, just to prove I could.
gigawhitlocks | 15 hours ago
For whatever it is worth, I have always thought the use of client certificates was one of the most compelling parts of Gemini. I saw them used in a clever ways at least once, and have long felt they are underutilized.
xq | 8 hours ago
i still feel guilty for abandonding the Kristall browser, because
it does actually support markdown viewing/rendering
gwil | 4 hours ago
I would really love to hear more of your thoughts on this.
gerikson | 3 hours ago
Not GP, but here are my thoughts on the matter from 2021:
https://gerikson.com/blog/comm/Gemini-misaligned-incentives.html#dev
classichasclass | 12 hours ago
If we're measuring active Gemini sites, I agree there are almost certainly more of them.
If we're measuring absolute resources available, I think this is arguable due to the archival content many of the active Gophers maintain. I see very few of this sort of thing on Gemini.
Not that it really matters much :) but we should be specific on the stats.
spc476 | 12 hours ago
There are only around 300 or so known gopher servers running, whereas Gemini has I think low-4 figures. But yes, there are some very large gopher servers in that 300.
hongminhee | 4 hours ago
One thing I haven't seen mentioned: Gemtext's stripped-down markup isn't just an inconvenience. For some languages it's closer to a fundamental barrier.
Japanese ruby annotations (
<ruby>in HTML) exist precisely because there's no other reasonable way to gloss kanji with furigana in running text. This isn't a presentational nicety; it's how you make a text legible to readers who might not know a given character. Traditional Mongolian script runs top-to-bottom, with columns progressing left-to-right. Without something equivalent to CSSwriting-mode, the text doesn't render awkwardly, it just can't be rendered correctly at all. Arabic and Hebrew need proper bidirectional text handling; Thai has no word separators, so rendering it correctly requires the kind of line-breaking logic that plain text pipelines tend to quietly ignore; Tibetan and Khmer rely on complex ligature and stacking behaviour that falls apart without thoughtful font and layout support.HTML's
<ruby>element, for what it's worth, came from a real internationalization need. Microsoft introduced it for Internet Explorer 5 specifically because East Asian users needed it, and it eventually made it into the W3C standard. That's not the kind of complexity that crept in because advertisers wanted it. It's the kind that accumulated because the web was, at least sometimes, actually trying to accommodate how people write.I think the Gemini designers were imagining a hypothetical average writer who uses a Latin alphabet, left to right, with no need for anything beyond ASCII-adjacent text semantics. That's a pretty specific person to design around and call it “simple.” Simplicity that only works for a subset of human writing systems isn't really simplicity. It's just a different set of assumptions made invisible by familiarity.
gerikson | 3 hours ago
Even for European-centric authoring, there's basic deficiencies in gemtext. The lack of standardized bold or italic means you can't refer to citations (as in an academic context) etc. in a standard manner.
I gave Gemini publishing a fair shake but bounced off it. Nowadays I just rant in HTML, as God intended...
matthiasportzel | 2 hours ago
This feels unfair because nothing in the protocol is ASCII specific, documents are UTF-8. Maybe you’re right that someone who is able to communicate in UTF-8 is a western strawperson and that inline HTML support is required for Japanese speakers so that they can include <ruby> elements, but that hardly seems like Gemini’s problem. If you can’t author a coherent text-based document in UTF-8 it seems like you should bring that up with the Unicode consortium.
hongminhee | an hour ago
The encoding/rendering distinction matters here. UTF-8 encoding furigana and kanji is trivial; the question is whether you can express that a run of hiragana is a gloss on a specific kanji, attached to it, rendered above it. That relationship is what
<ruby>encodes, and it has no equivalent in plain text. Writing漢字（かんじ）is a workaround, not the same thing.The Unicode consortium point is a non-sequitur: Unicode handles codepoints, not layout. Mongolian vertical text, Arabic bidi, Thai word-breaking—these are rendering problems, not encoding problems, and they're not Unicode's jurisdiction.
I'd also gently push back on “hardly seems like Gemini's problem.” That framing accepts the premise: Gemini genuinely can't do these things. My point was that this isn't a neutral technical tradeoff. It's a design choice that happens to be costless for Latin-alphabet writers and fairly significant for others.
matthiasportzel | an hour ago
I think the problem is that we call Gemini documents “documents.” It short circuits people’s brains. They go, “oh, like LaTeX documents” and then they’re suddenly unable to live without footnotes and inline images and bold and underline and table of contents and mathematical expressions. There was one guy who was working on a project to convert some textbooks to Gemtext, and he got hung up on the lack of inline math support.
But of course, all these same people go and post on Twitter or Facebook and don’t complain about a lack of <ruby> elements or any other HTML element for that matter. Maybe if we just called them “Gemini posts” then people would understand that they’re fundamentally plain-text and just happen to have headers.
hongminhee | an hour ago
The “posts not documents” reframe doesn't really rescue the argument. Gemini's own stated goal is to be a space for publishing content that would otherwise live on the web. If the scope is actually “just posts, like Twitter,” that's a significant step down from the project's own ambitions.
And the Twitter/Facebook comparison works against the point being made. Facebook has invested heavily in internationalization: it handles Arabic and Hebrew bidirectional text, Thai line-breaking, and a range of complex scripts reasonably well precisely because those are real requirements for a platform with a global user base. It's a case where a commercial platform did the work that Gemini's designers opted out of.
The “just call them posts” solution is cosmetic. Renaming the format doesn't change what it can and can't express.
dzwdz | 17 hours ago
Just four days ago ew0k announced they're shutting down Antenna (http proxy) :(
I don't really participate in the Gemini community but I do like the project a lot, and Antenna was pretty much the front page of
the internetGemini for me. It's sad to see it go; I'm worried the ecosystem will split up such that we will no longer have such a single "front page". Still, I hope a worthy replacement will spring up.gerikson | 16 hours ago
It's a bit less dramatic than that, they're asking someone to take it over.
manuel | 3 hours ago
Markdown is extremely hard to parse. Please refer to https://github.github.com/gfm/
[OP] chai | 17 hours ago
I found this article linked from The “small web” is bigger than you might think, which I think is interesting, but not quite on-topic enough to be submitted as its own article here.
However, the experience of using Gemini, especially as it's had some time to grow, is an interesting topic, especially the rough edges that the author has run into, and the alternatives that have sprung up in the years since its introduction.
koala | 6 hours ago
I still think Gemini is important.
Gemini is performance art. It shows us how the web can be for some purposes. It shows how something that you can code in a couple of hours can do some stuff better than stuff no one can code (Microsoft gave up on maintaining a browser engine).
One thing I mentioned in IRC the other day that I think is not as well known is the Gemini subscription specification. Instead of RSS, gemtext pages can have an implicit feed by having multiple links with dates in them.
This sounds like something minor, but I think it's not. Nowadays, if you want to write a simple blog, you could do it with very simple tools... except for the RSS feed, which is a pain to write by hand. With Gemini you can create a subscribable blog with... just a text editor without a huge effort.
(My current blog uses this idea- I convert the gemtext to HTML and my converter adds an RSS feed if the gemtext contains an implicit feed.)
(Of course, yesterday I also faced the reality again that I'm slowly drifting apart from RSS feeds. That was not a happy place.)
My current setup is also designed to do this. Basically I've configured Apache to do MultiViews, serving both gemtext and HTML, and then my Gemini server is just a dumb proxy that is virtual host-capable. My server is designed to be a tilde, and for instance my
~userwebsite is also served onmydomain.example.com. I would like to "productize" this a bit.ethoh | 8 hours ago
I stick to gopher, although Spartan is interesting.
The TLS and UTF-8 requirements, as well as not being able to query size before fetching, make Gemini too annoying, and as the protocol cannot evolve, it is non-fixable (by design).
spc476 | 7 hours ago
What's wrong the the UTF-8 requirements? It's the default, not mandatory. You can send "text/gemini; charset=iso8859-1" as the MIME type.
Also, I did make a suggestion about sending the size of the resource, but Solderpunk said no. I tried.