I'll add my name to the list of people who like the idea and were very curious about it when they first heard about it but now don't think about it as much.
It's very fun to develop for. The simplicity of the protocol means that writing a server, client or "web app" (equivalent) is a weekend project. So there is a proliferation of software for it but that doesn't necessarily translate into content.
There is content, though. My favourite aggregator is gemini://warmedal.se/~antenna/ and I do still drop by there regularly enough to have a browse. It's no longer all meta content which is good (people used to just use Geminispace to write about Gemini). It's still quite tech/FOSS focused, unsurprisingly.
I agree with the other comments that are saying that a simple markdown would have been better than gemtext.
Whenever Gemini gets mentioned on HN there are a lot of commenters who seem to have an issue with the "views" or "values" of some people within the community. They never go into detail. I can honestly say I'm not sure what the issue is. As a very middle-of-the-road centrist I have never had much of an issue with the content I find on Gemini. Sure, you had a few interesting "characters" on the mailing list (back when it existed) but they were a minority and it was nothing you don't also find on the web. I guess people there tend to be more dogmatic about sticking to FOSS and keeping the internet non-corporate, which can rub people the wrong way, but again you can find similar views on the web (and IMO it makes for interesting discussions even if I don't agree with the dogmatism).
As an early adopter and developer of a couple of service oriented capsules, as time went by my interest faded completely. I'm a strong advocate of live and let live, so this is not a critique or discouragement post, but rather my own perspective.
Like many have mentioned already, I personally would have preferred pure markdown and no gemtext at all. Similarly, and although I understand the reasoning behind making encryption mandatory, I believe it should be optional in the spirit of KISS. I'm more of a minimalist than I am a privacy evangelist. In this regard, I felt a bit out of place within the gemini community.
Finally, the argument that it takes a new protocol to avoid a broken user experience, often exemplified by someone jumping from a simple and well behaved HTTP website into a chaotic one, doesn't resonate much with me. Again, I get it, but I can live with visiting only the websites or gopherholes I want. This comes with a great advantage. Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules. I missed a broader set of topics when I used gemini and ultimately that was what killed my interest.
All that said, I loved it while I used it and I stumbled upon some really nice people. Maybe I'll fall in love again one day...
> Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules. I missed a broader set of topics when I used gemini and ultimately that was what killed my interest.
This is definitely Gemini's biggest weakness. I looked around on it a bit when it was gaining attention, and most of the sites I saw were just complaints about how bloated the modern web had become. I get it, but it's kind of treating the whole thing as a novelty rather than an actual medium that can be used to convey information. It didn't have the wide and varied userbase that even the mid-90s academic web they were trying to replicate had. It kind of reminded me of all the people who write a static site generator for their blog, and then only write a single blogpost about how they made their static site generator.
There is some good information to be found actually, although it is true that it is not much. However, if you have something to write, then you can write it, and then if they are published then there will be more things to read.
The thing I liked about Gemini and its self-imposed limitations is that it was very much impossible to create a misbehaving Gemini document. There is no way a Gemini browser will phone home, run malicious code on my side, grab/upload my browser history or send sensor or other data because I forgot to turn off various options, etc. To me the entire thing was much more trustworthy.
You can of course recreate this experience using HTTP and modern browsers, but both are so complicated that you don't know what's really happening without a lot of work.
This should really be a more common feature in web browsers. Yes, it can be achieved by turning off JavaScript and so on but it should be a feature like Incognito mode where you have either a high visibility toggle button, or open tabs in this mode, where tabs with the same kind as the parent keeps being opened in this mode. That way, you’d have Gemini for the regular web just by making websites that don’t break when that kind of code is disabled.
I liked that as well, but wouldn't remember it before reading your comment. I guess all in all it is a pretty nice protocol, the only real problem for me is that the content is too niche to appeal to me on a daily basis.
> Again, I get it, but I can live with visiting only the websites or gopherholes I want. [...] Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules.
I agree. Personally, I'm a fan of progressive enhancement.
E.g. I use this Hugo partial to hide emails; it de-obfuscates an address using JavaScript, and falls back to printing a shell command:
I can attest that CSS is very effective for obfuscating e-mail.
I displayed my academic e-mail on my webpage for over half a decade using CSS to flip the text direction[1] without getting significant spam.
This kind of approach is exactly why I believe we can have a nice experience over HTTP. Progressive content enhancement nails the perfect balance between too simple and too bloated. I personally believe client side scripting is important and ideally should be used sparingly. Your example illustrates a perfectly reasonable use case where JavaScript makes sense, yet still providing a scriptless alternative that solves the problem. Nice stuff.
> I personally would have preferred pure markdown and no gemtext at all
The gemtext format is much simpler than markdown, which can avoid the complexity of handling markdown files. (One thing I dislike about markdown and other text-based formats (including JSON, etc) is that escaping will then be required, which can make it messy).
(Nevertheless, you can serve files of any format like you can with HTTP and some other protocols.)
> Similarly, and although I understand the reasoning behind making encryption mandatory, I believe it should be optional in the spirit of KISS
I agree. (My own "Scorpion" protocol does make it optional, for this reason. However, the existing server implementation does not currently implement TLS, although the protocol does allow (and also recommend) it, as long as any files that do not require X.509 client authentication can also be accessed without TLS.)
(Also, if you are serving only static files with Gemini then you could also use Spartan which uses the same file format as Gemini. If you have dynamic files, then it is going to be more difficult because of the differences between the protocols, although it might still be possible.)
> Finally, the argument that it takes a new protocol to avoid a broken user experience, often exemplified by someone jumping from a simple and well behaved HTTP website into a chaotic one [...]
This might miss the point. As the FAQ mentions, there are benefits of a new protocol and file format, including a simplified implementation compared with HTML, and this does not prevent the possibility of also making and/or using well designed websites.
(If you specifically do want a subset of HTTP, HTML, and JavaScript, there is "gemiweb0", and is intended to also be compatible with common web browsers. However, this does not mean that Gemini and other protocols and file formats are worthless; they are still beneficial, in my opinion.)
Regardless of the technical shortcomings of the protocol, a grassroots group of individuals has managed to create a viable new network protocol. The user base is small, but it is not tiny and it is not nonexistent and it has been going for years now. You can download a Gemini client and find regularly updated blogs on a Gemini search engine. You can have discussions on Gemini applications like Antenna or Station. It has managed to solve many of the problems it intended to solve (privacy, resource bloat, protocol specification bloat, etc.).
I’m pretty sure they talk about privacy directly in the spec, but I haven’t read the spec in years. Going off the top of my head, they had the decision to not include things like user agent headers or anything that resembles a cookie specifically with the goal of preserving privacy. There is also the obvious point of the protocol not supporting raw TCP sockets and requiring encryption by default.
Thanks. For this that don't want to have to click through:
Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
It was sad seeing the hate for it on here when it was new-ish, and while I haven't used it in a while, I'm glad to see it still kicking around. Such a neat and fun project.
I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.
The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.
HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.
If you want to build new and smaller communities, I really think we should be building for browsers. Perhaps a website design manifesto is in order.
The limits of the medium and the creativity this enforces is why people like it. It caters a niche audience with a shared set of values. I get why people don't really care for it personally or on a technical level (myself included), but it always surprises me that it's hard for people to understand that others do.
> The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.
That is a microscopic subset of the modern web.
I don't use Gemini— though I am highly tempted —but I expect some of the attraction is that you can click on any link and pretty much guaranteed not to be socked in the face with a sign-up-for-my-newsletter or cookies-accept-all-yes-later or paragraph-ad-paragraph-ad-paragraph-ad or fiddling with NoScript to find the minimum amount of Javascript that will let you read some article that looks interesting. In Gemini, all that friction just goes away.
HTTP is intermingled with a lot of the shitty SPAs, advertising and SEO of the web. You can make a simple text only site but the noise of the modern web is only ever a couple of clicks away. Gemini silos itself off. You know that a link you click will be an equally clean text-first site. To me that is the feature.
I’ve been exploring this problem for a while, and have been building something which I think might help solve it.
I’m currently building a browser-based static site generator that produces clean, simple code. But it does more than that.
Alongside the generated HTML, sites also publish their public configuration and source files, meaning they can be viewed in more than just a browser, for example in a CLI or accessibility device.
The client interface is also more than a CMS - you’ll be able to follow other sites, subscribing to updates, and build a network rather like a webring. The idea is to provide human-powered discovery and community tools. The reach may be less than if algorithmic, but it’s designed for genuine connection, not virality.
As the client is smart but sites are simple, sites can be hosted on anything, from the cheapest shared host up.
I’d be happy to talk further if that’s interesting in any way.
HTTP is great but with AI crawling being all over the place maybe it is not a bad idea to publish in a safe / niche place if one is not obsessed on how much people will be reached.
I am saying this but I have no idea if AI crawlers have started to crawl gem capsules.
> I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.
I'm not sure I understand that. HTTP is the fundamental protocol of the web. If your goal is to create an ecosystem that is deliberately set apart from the web, how would using the same underlying tech stack help rather than hinder you in doing that?
> HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.
And why are those sites so awful? Did they decide to become awful from the outset, or is it because they've gradually adapted to a userbase that has regressed to the mean due to the mass-market nature of the web?
The whole point of developing a new protocol is to create a non-negligible threshold of though and effort for participation, precisely so that it doesn't get popular quickly and end up subjected to Eternal September.
Its a fun concept but the community around it had a strong tendency to want to proselytize their values to you. I enjoyed playing around with it in the beginning but it introduced me to too many tech preachers each with their own similar but slightly different philosophies that they felt like I must know about.
It may have changed but that's what largely turned me off from it. I find other networking projects to have a less preachy mix of people.
The selection effects of people seeking out something like this are probably intense, but that was also true for the early web, and is what people liked about the early web.
The biggest thing I’ve seen is outsiders who find protocol issues to be non-starters. It’s certainly not a perfect protocol, but neither is HTTP or email. It works and I’m happy that we have another option for hypermedia.
There were people questioning decisions in relation to goals they were projecting onto the project, but which were not actually the goals of the project. That often resembles 'hate'.
The thing about Gemini is that it reads like someone who thinks Gopher sounds neat but has only ever dealt with HTTP and HTML/Markdown... so they took HTTP GET, chopped a digit off the response codes, and called it a new protocol, then tacked on an intentionally-broken Markdown implementation (more broken than the original Markdown, I mean).
Interesting note: the first line of a Gemini response is a MIME type. It's usually `text/gemini` but there's no reason it can't be `text/html`, `application/javascript`, or anything else. A while back I did a little poking in some Gemini server code and made it do precisely that: serve HTML files which I accessed via elinks. Of course once you're serving HTML over Gemini you might ask, exactly what advantage am I getting by putting it over a purposefully-broken subset of HTTP, and I would say that's a damn good question.
In 2024 I wrote 'The modern Web and all its crappiness didn't come about because there's something inherently wicked in HTML and HTTP, it came about because people built things on top of the basic foundation, extending (sometimes poorly) and expanding. The more people play with Gemini, the more they'll want to "extend" it... and the closer they'll bring it to HTTP, because it follows the exact same fundamental model once you strip off the extraneous document format specification' and I stand by it.
So you're right, they didn't extend the Gemini protocol, they created an entirely new protocol which many clients, servers, and libraries now implement because the functionality was desirable.
Wonder what they'll call the protocol that implements DELETE... maybe Deorbit?
I wrote a server for it a while back (am still running it someplace behind a CF tunnel) but I’ve never really found either the community or the protocol were taking off:
A key issue with the ecosystem (not the protocol) as far as I’m concerned is that it would have been stupendously better to settle on Markdown (even a simplified form) for content creation. The rest is OK, I guess, but it’s just a nuisance to maintain “dual format” sites.
(I see a few comments here about the community’s opinions and leanings, but to be honest it’s not any weirder than your average old-timely IRC channel or fringe Mastodon server—-live and let live, read what you want and just skip Antenna listings you don’t like)
It is possible if you restrict yourself to an subset of markdown. It works pretty well, actually, i have two awk scripts that take in a subset of markdown and generate either HTML or LaTeX.
There are far more gopher phlogs than gemini gemlogs.
Still, both communities overlap of course.
Setting up a gopher phlog requires no TLS at all and any machine from 1980 (even maybe ITS
with a Gopher client written in MacLisp) will be able to read it with no issues.
I love the frugality, overall project goals, and I'm used to non mainstream ergonomics (I enjoy gnu ed..). But something about Gemini search engines and browsing was unfit for me to keep using it.
However, it works on the basis of mandatory-prohibition. The prohibition is: "You cannot track and exploit your site visitors". This philosophy is enforced 'remotely', by the creators of the Gemini protocol.
An identical end-result can be achieved in HTML, by choosing not to use hostile markup. However, with HTML the prohibition must be enforced 'locally', by the ethical-philosophical position of the website-designer.
The problem with the Gemini-protocol is that it introduces an attack vector: The Gemini 'browsers' themselves. The most popular one is not audited; has a huge code-base; and has relatively few eyes-on-it.
I'm not saying that Gemini protocol is a honey-trap for those trying to exit the surveillance-internet; but if I was a tech-giant / agency profiting from the surveillance-internet, I would definitely write browsers for the Gemini protocol and backdoor them.
As a former "Don't be evil" company, it would be of great interest to me who was trying to exit my 'web'; how; and why :)
Despite the specification, there is such possibilities as TLS fingerprinting, URL tracking, although it does reduce much of the problems of WWW.
> The problem with the Gemini-protocol is that it introduces an attack vector: The Gemini 'browsers' themselves. The most popular one is not audited; has a huge code-base; and has relatively few eyes-on-it.
You do not have to use the most popular one (I don't use the most popular one); there are many others available as well, and the specification is made that you could hopefully make your own one if you like to do, too.
> if I was a tech-giant / agency profiting from the surveillance-internet, I would definitely write browsers for the Gemini protocol and backdoor them.
Nobody is required to use that specific implementation, and someone might find the backdoors, but it is possible.
> As a former "Don't be evil" company, it would be of great interest to me who was trying to exit my 'web'; how; and why :)
You do not necessarily need to write a new browser to check this; sometimes they already write public documents about these things, and there are many other ways to track it (e.g. by logging other things, by tracking browser extensions, etc).
The whole point of Gemini's simplicity and designed-in lack of evolution (through missing version numbers) is that you can write a fully featured client yourself, because the protocol surface is not that large once you leverage an existing TLS library.
the userbase for gemini is so miniscule, I can't imagine they could get enough data to want to even bother. Bit like trophy fishing in the puddle of rain runoff next to the stocked pond of monster bass.
Gemini for me has been such a breath of fresh air in contrast to 2025 Internet, with so many ads, grift and now AI slop.
Back when I first discovered Gemini, I wanted to create a space for people to have a voice without needing to run their own server, so I built Station (https://martinrue.com/station). I've been running it ever since.
Gemini in general, and specifically folk who use Station regularly, make it a friendly, throwback-to-the-90s vibe, and I still value it a lot.
Gemini the protocol is still a bit mysterious to me. Why not use plain HTTPS and just serve a new text/x.gemini MIME type? Or even serve plain old text/html and enforce no-JS-or-CSS in the Gemini client.
Part of the goals of making it so tiny, as far as I understand it, is that a normal person could reasonably implement the entire thing from server to client. Going full HTTPS and HTML is a bit of a lift for a single person in a short period of time
I like Gemini. My (anonymous) blog (gemlog) is posted there and has an http proxy, and is a no-brainer to maintain.
Once in a while I check Lagrange (Gemini "browser") for gemlogs I've subscribed to and catch up with what other anons are going through. It tends to be a lot more raw and persona-less than what I find on the web, which I appreciate. It's generally just cozy.
I noted there were a few capsules that acted as a sort of hub for other peoples capsules. which suggested to me there was a way to automate it, and I might be able to make my own
I love the idea, but it's just to fringe to use for me. But I will say that I think the internet was far better before Google search really became strong, and before the corresponding massive increase in SEO spam.
The author very much did allow others to give input. The original protocol had single digit status codes, I was arguing for three digit codes, he compromised with two digit codes. It was my idea to include the full URL for requests, and for redirections. It's just that it wasn't easy, but he could be reasoned with. The only two hard lines Solderpunk had for the protocol was TLS, and single level lists (why, I don't know).
Gopher user there from texto-plano (and seldomly, SDF).
Gopher often sucks for 40x25 devices or mobile ones.
Yes, word wrapping, but everyone uses the 72 char limit
or even doesn't give a heck and I have to set
my own $PAGER calling fmt, fold or par before less.
On TLS, you are right. But I've got to build BearSSL and some
libreSSL for for Damn Small Linux. The 2.4 kernel one,
were ALSA was a novely and DMIX was hard to set,
the one you got with Debian Woody... with the bf24 at
the LILO prompt.
So, if DSL can run some BearSSL based OpenSSL-lite
client, a gemini client for it should be totally doable.
That's not narcissism - it's just someone building something they enjoy and sharing it with the world. Do you have the same objections to fiction writers or songwriters?
It's totally fine to prefer gopher for its maturity (I'd vehemently disagree, but that's for another day) or compatibility with retro machines, but framing someone else's creative project as a character flaw is just rude.
I think Gemini is a step in the right direction for some things. I usually mention my "tersenet" ideas when I see Gemini. Now that we have the Gemini LLM and Claude etc. there is less excuse for me to not finish any real software demo for it. Maybe one these days I will make an actual client for part of it.
I think there is room for things like media and applications even on an idealized web. But they should not necessarily be combined along with information browsing and search into one thing.
> I think Gemini is a step in the right direction for some things.
I also think so, although I have criticisms of it too (e.g. mandatory TLS; I think optional (except files that require authentication for access) would be better), but nevertheless it can be used.
> I usually mention my "tersenet" ideas when I see Gemini
I have seen TerseNet, and I mentioned it in my "small web" document. I think it is good that media and programs are not loaded automatically, although there are other problems with TerseNet in my opinion, such as text being limited to 5K.
> I think there is room for things like media and applications even on an idealized web. But they should not necessarily be combined along with information browsing and search into one thing.
I agree, it is helpful, and they should be separated.
I also made up a protocol and file format specification, in order to deal with the criticisms of the other ones. In addition to avoiding many things, there is also adding things which would be useful, beyond what WWW and others might do. So, it is not strictly a subset of the functions of WWW, even though many things are deliberately avoided.
I'll add my name to the list of people who like the idea and were very curious about it when they first heard about it but now don't think about it as much.
It's very fun to develop for. The simplicity of the protocol means that writing a server, client or "web app" (equivalent) is a weekend project. So there is a proliferation of software for it but that doesn't necessarily translate into content.
There is content, though. My favourite aggregator is gemini://warmedal.se/~antenna/ and I do still drop by there regularly enough to have a browse. It's no longer all meta content which is good (people used to just use Geminispace to write about Gemini). It's still quite tech/FOSS focused, unsurprisingly.
I agree with the other comments that are saying that a simple markdown would have been better than gemtext.
Whenever Gemini gets mentioned on HN there are a lot of commenters who seem to have an issue with the "views" or "values" of some people within the community. They never go into detail. I can honestly say I'm not sure what the issue is. As a very middle-of-the-road centrist I have never had much of an issue with the content I find on Gemini. Sure, you had a few interesting "characters" on the mailing list (back when it existed) but they were a minority and it was nothing you don't also find on the web. I guess people there tend to be more dogmatic about sticking to FOSS and keeping the internet non-corporate, which can rub people the wrong way, but again you can find similar views on the web (and IMO it makes for interesting discussions even if I don't agree with the dogmatism).
As an early adopter and developer of a couple of service oriented capsules, as time went by my interest faded completely. I'm a strong advocate of live and let live, so this is not a critique or discouragement post, but rather my own perspective.
Like many have mentioned already, I personally would have preferred pure markdown and no gemtext at all. Similarly, and although I understand the reasoning behind making encryption mandatory, I believe it should be optional in the spirit of KISS. I'm more of a minimalist than I am a privacy evangelist. In this regard, I felt a bit out of place within the gemini community.
Finally, the argument that it takes a new protocol to avoid a broken user experience, often exemplified by someone jumping from a simple and well behaved HTTP website into a chaotic one, doesn't resonate much with me. Again, I get it, but I can live with visiting only the websites or gopherholes I want. This comes with a great advantage. Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules. I missed a broader set of topics when I used gemini and ultimately that was what killed my interest.
All that said, I loved it while I used it and I stumbled upon some really nice people. Maybe I'll fall in love again one day...
gluon
> Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules. I missed a broader set of topics when I used gemini and ultimately that was what killed my interest.
This is definitely Gemini's biggest weakness. I looked around on it a bit when it was gaining attention, and most of the sites I saw were just complaints about how bloated the modern web had become. I get it, but it's kind of treating the whole thing as a novelty rather than an actual medium that can be used to convey information. It didn't have the wide and varied userbase that even the mid-90s academic web they were trying to replicate had. It kind of reminded me of all the people who write a static site generator for their blog, and then only write a single blogpost about how they made their static site generator.
There is some good information to be found actually, although it is true that it is not much. However, if you have something to write, then you can write it, and then if they are published then there will be more things to read.
2 replies →
The thing I liked about Gemini and its self-imposed limitations is that it was very much impossible to create a misbehaving Gemini document. There is no way a Gemini browser will phone home, run malicious code on my side, grab/upload my browser history or send sensor or other data because I forgot to turn off various options, etc. To me the entire thing was much more trustworthy.
You can of course recreate this experience using HTTP and modern browsers, but both are so complicated that you don't know what's really happening without a lot of work.
This should really be a more common feature in web browsers. Yes, it can be achieved by turning off JavaScript and so on but it should be a feature like Incognito mode where you have either a high visibility toggle button, or open tabs in this mode, where tabs with the same kind as the parent keeps being opened in this mode. That way, you’d have Gemini for the regular web just by making websites that don’t break when that kind of code is disabled.
HTTP has infinitesimal complexity compared to basically any other feature of a browser.
I liked that as well, but wouldn't remember it before reading your comment. I guess all in all it is a pretty nice protocol, the only real problem for me is that the content is too niche to appeal to me on a daily basis.
Instead of inventing a separate protocol, you can invent your own html meta tag that marks a website to be JavaScript-free.
This will let you create search engines that crawl and index these sites specifically.
4 replies →
> Again, I get it, but I can live with visiting only the websites or gopherholes I want. [...] Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules.
I agree. Personally, I'm a fan of progressive enhancement.
E.g. I use this Hugo partial to hide emails; it de-obfuscates an address using JavaScript, and falls back to printing a shell command:
(Hopefully HN will preserve all the characters.)
Similar for CSS, although that one is a forever WIP...
I can attest that CSS is very effective for obfuscating e-mail. I displayed my academic e-mail on my webpage for over half a decade using CSS to flip the text direction[1] without getting significant spam.
[1] https://superuser.com/a/235965
This kind of approach is exactly why I believe we can have a nice experience over HTTP. Progressive content enhancement nails the perfect balance between too simple and too bloated. I personally believe client side scripting is important and ideally should be used sparingly. Your example illustrates a perfectly reasonable use case where JavaScript makes sense, yet still providing a scriptless alternative that solves the problem. Nice stuff.
> I personally would have preferred pure markdown and no gemtext at all
The gemtext format is much simpler than markdown, which can avoid the complexity of handling markdown files. (One thing I dislike about markdown and other text-based formats (including JSON, etc) is that escaping will then be required, which can make it messy).
(Nevertheless, you can serve files of any format like you can with HTTP and some other protocols.)
> Similarly, and although I understand the reasoning behind making encryption mandatory, I believe it should be optional in the spirit of KISS
I agree. (My own "Scorpion" protocol does make it optional, for this reason. However, the existing server implementation does not currently implement TLS, although the protocol does allow (and also recommend) it, as long as any files that do not require X.509 client authentication can also be accessed without TLS.)
(Also, if you are serving only static files with Gemini then you could also use Spartan which uses the same file format as Gemini. If you have dynamic files, then it is going to be more difficult because of the differences between the protocols, although it might still be possible.)
> Finally, the argument that it takes a new protocol to avoid a broken user experience, often exemplified by someone jumping from a simple and well behaved HTTP website into a chaotic one [...]
This might miss the point. As the FAQ mentions, there are benefits of a new protocol and file format, including a simplified implementation compared with HTML, and this does not prevent the possibility of also making and/or using well designed websites.
(If you specifically do want a subset of HTTP, HTML, and JavaScript, there is "gemiweb0", and is intended to also be compatible with common web browsers. However, this does not mean that Gemini and other protocols and file formats are worthless; they are still beneficial, in my opinion.)
Regardless of the technical shortcomings of the protocol, a grassroots group of individuals has managed to create a viable new network protocol. The user base is small, but it is not tiny and it is not nonexistent and it has been going for years now. You can download a Gemini client and find regularly updated blogs on a Gemini search engine. You can have discussions on Gemini applications like Antenna or Station. It has managed to solve many of the problems it intended to solve (privacy, resource bloat, protocol specification bloat, etc.).
What did it do for privacy?
I think Gemini is great, and read from Nyxt browser. Don't know if I've seen any references to privacy benefits, so curious.
I’m pretty sure they talk about privacy directly in the spec, but I haven’t read the spec in years. Going off the top of my head, they had the decision to not include things like user agent headers or anything that resembles a cookie specifically with the goal of preserving privacy. There is also the obvious point of the protocol not supporting raw TCP sockets and requiring encryption by default.
For those that were thinking of the LLM and don’t know what this is, like me, their FAQ details what it is: https://geminiprotocol.net/docs/faq.gmi
Thanks. For this that don't want to have to click through:
Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
It was sad seeing the hate for it on here when it was new-ish, and while I haven't used it in a while, I'm glad to see it still kicking around. Such a neat and fun project.
I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.
The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.
HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.
If you want to build new and smaller communities, I really think we should be building for browsers. Perhaps a website design manifesto is in order.
The limits of the medium and the creativity this enforces is why people like it. It caters a niche audience with a shared set of values. I get why people don't really care for it personally or on a technical level (myself included), but it always surprises me that it's hard for people to understand that others do.
2 replies →
> The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.
That is a microscopic subset of the modern web.
I don't use Gemini— though I am highly tempted —but I expect some of the attraction is that you can click on any link and pretty much guaranteed not to be socked in the face with a sign-up-for-my-newsletter or cookies-accept-all-yes-later or paragraph-ad-paragraph-ad-paragraph-ad or fiddling with NoScript to find the minimum amount of Javascript that will let you read some article that looks interesting. In Gemini, all that friction just goes away.
61 replies →
HTTP is intermingled with a lot of the shitty SPAs, advertising and SEO of the web. You can make a simple text only site but the noise of the modern web is only ever a couple of clicks away. Gemini silos itself off. You know that a link you click will be an equally clean text-first site. To me that is the feature.
I’ve been exploring this problem for a while, and have been building something which I think might help solve it.
I’m currently building a browser-based static site generator that produces clean, simple code. But it does more than that.
Alongside the generated HTML, sites also publish their public configuration and source files, meaning they can be viewed in more than just a browser, for example in a CLI or accessibility device.
The client interface is also more than a CMS - you’ll be able to follow other sites, subscribing to updates, and build a network rather like a webring. The idea is to provide human-powered discovery and community tools. The reach may be less than if algorithmic, but it’s designed for genuine connection, not virality.
As the client is smart but sites are simple, sites can be hosted on anything, from the cheapest shared host up.
I’d be happy to talk further if that’s interesting in any way.
3 replies →
HTTP is great but with AI crawling being all over the place maybe it is not a bad idea to publish in a safe / niche place if one is not obsessed on how much people will be reached.
I am saying this but I have no idea if AI crawlers have started to crawl gem capsules.
> I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.
I'm not sure I understand that. HTTP is the fundamental protocol of the web. If your goal is to create an ecosystem that is deliberately set apart from the web, how would using the same underlying tech stack help rather than hinder you in doing that?
> HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.
And why are those sites so awful? Did they decide to become awful from the outset, or is it because they've gradually adapted to a userbase that has regressed to the mean due to the mass-market nature of the web?
The whole point of developing a new protocol is to create a non-negligible threshold of though and effort for participation, precisely so that it doesn't get popular quickly and end up subjected to Eternal September.
6 replies →
Its a fun concept but the community around it had a strong tendency to want to proselytize their values to you. I enjoyed playing around with it in the beginning but it introduced me to too many tech preachers each with their own similar but slightly different philosophies that they felt like I must know about.
It may have changed but that's what largely turned me off from it. I find other networking projects to have a less preachy mix of people.
The selection effects of people seeking out something like this are probably intense, but that was also true for the early web, and is what people liked about the early web.
1 reply →
The biggest thing I’ve seen is outsiders who find protocol issues to be non-starters. It’s certainly not a perfect protocol, but neither is HTTP or email. It works and I’m happy that we have another option for hypermedia.
I don't remember there being hate. I remember a lot of people, including myself, questioning Gemini's decisions. E.g. https://news.ycombinator.com/item?id=33470229
There were people questioning decisions in relation to goals they were projecting onto the project, but which were not actually the goals of the project. That often resembles 'hate'.
The thing about Gemini is that it reads like someone who thinks Gopher sounds neat but has only ever dealt with HTTP and HTML/Markdown... so they took HTTP GET, chopped a digit off the response codes, and called it a new protocol, then tacked on an intentionally-broken Markdown implementation (more broken than the original Markdown, I mean).
Interesting note: the first line of a Gemini response is a MIME type. It's usually `text/gemini` but there's no reason it can't be `text/html`, `application/javascript`, or anything else. A while back I did a little poking in some Gemini server code and made it do precisely that: serve HTML files which I accessed via elinks. Of course once you're serving HTML over Gemini you might ask, exactly what advantage am I getting by putting it over a purposefully-broken subset of HTTP, and I would say that's a damn good question.
In 2024 I wrote 'The modern Web and all its crappiness didn't come about because there's something inherently wicked in HTML and HTTP, it came about because people built things on top of the basic foundation, extending (sometimes poorly) and expanding. The more people play with Gemini, the more they'll want to "extend" it... and the closer they'll bring it to HTTP, because it follows the exact same fundamental model once you strip off the extraneous document format specification' and I stand by it.
> The more people play with Gemini, the more they'll want to "extend" it... and the closer they'll bring it to HTTP
Then it's not Gemini. Interestingly this is why it was decided for Gemini not to have a protocol version. To prevent extension.
2019: Gemini introduced
2022-ish: Titan created (based on existed of https://web.archive.org/web/20220126075826/https://transjovi...).
The spec for Titan (https://portal.mozz.us/gemini/transjovian.org/titan/page/The...?) appears to be an implementation of PUT for Gemini, but since Gemini doesn't have verbs (GET is implied) it does it by creating a whole new "protocol" titan://
So you're right, they didn't extend the Gemini protocol, they created an entirely new protocol which many clients, servers, and libraries now implement because the functionality was desirable.
Wonder what they'll call the protocol that implements DELETE... maybe Deorbit?
Edit: oh there's also Spartan (2022), another protocol which is Gemini but if there are bytes after the request line, it's an implicit PUT: https://raw.githubusercontent.com/michael-lazar/spartan/refs...
2 replies →
I wrote a server for it a while back (am still running it someplace behind a CF tunnel) but I’ve never really found either the community or the protocol were taking off:
https://github.com/rcarmo/aiogemini
A key issue with the ecosystem (not the protocol) as far as I’m concerned is that it would have been stupendously better to settle on Markdown (even a simplified form) for content creation. The rest is OK, I guess, but it’s just a nuisance to maintain “dual format” sites.
(I see a few comments here about the community’s opinions and leanings, but to be honest it’s not any weirder than your average old-timely IRC channel or fringe Mastodon server—-live and let live, read what you want and just skip Antenna listings you don’t like)
Being able to parse gemtext line by line with almost no context is a big win for simplicity - you can't really do that with markdown.
It's not like by line but djot was designed to be parsed easier/more efficiently than markdown while being basically as featureful and ergonomic.
It is possible if you restrict yourself to an subset of markdown. It works pretty well, actually, i have two awk scripts that take in a subset of markdown and generate either HTML or LaTeX.
2 replies →
Uh, how much simplicity do you really gain? What's an instance of needing to backtrack?
1 reply →
Gemini is one of those things I see pop up and tell myself I should look into it more and then it fades into the back of my mind.
Anyone have any hints on getting more use out of it or ways to make it more present in my day to day.
NewsWaffle gemini://gemi.dev/cgi-bin/waffle.cgi/
takes a url to a regular webpage and spits out a gemtext version that is much more sparse and, for me, is much more readable.
For example, here's this very website:
gemini://gemi.dev/cgi-bin/waffle.cgi/feed?https%3A%2F%2Fnews.ycombinator.com%2Frss
it's honestly the only reason I still use gemini since the rest of it is abandoned gemlogs, rehosts of web content I don't care or ersatz social media
There are far more gopher phlogs than gemini gemlogs.
Still, both communities overlap of course.
Setting up a gopher phlog requires no TLS at all and any machine from 1980 (even maybe ITS with a Gopher client written in MacLisp) will be able to read it with no issues.
2 replies →
Oh nice, a gateway in the opposite direction!
I made the first (and still popular) "social network" 4 years ago. Still going strong. More info: https://martinrue.com/station
it's this federated with anything?
5 replies →
I love the frugality, overall project goals, and I'm used to non mainstream ergonomics (I enjoy gnu ed..). But something about Gemini search engines and browsing was unfit for me to keep using it.
Perhaps this may help: https://addons.mozilla.org/en-US/firefox/addon/geminize/
You will need to prefix a gemini URL with "gem " if you're pasting it into the address bar.
Kristall[1] is my favourite browser, Antenna[2] is my favourite aggregator.
Get browser, read some capsules!
[1]https://kristall.random-projects.net/ [2] gemini://warmedal.se/~antenna/
FWIW, I have moved my WEB site to Gemini an decided a little later to mirror it on gopher (for fun).
I find maintaining these 2 sites far easier then dealing with html and the *panels I need to use to upload to my old WEB site.
People who have never viewed Gemini are missing some decent content.
I checked out gemini maybe four years ago? And I remember really liking the idea but struggling to find content. Got any tips?
Here are a few more:
gemini://calcuode.com/gmisub-aggregate.gmi
gemini://nytpu.com/feed.gmi
gemini://skyjake.fi/lagrange/getting_started.gmi
gemini://gemini.circumlunar.space/capcom/
gemini://skyjake.fi/~Cosmos/
try gemini://sdf.org/ and gemini://gem.sdf.org/
Some stuff about archives of gemini:// and other SmolNet sites:
https://wiki.archiveteam.org/index.php/SmolNet
Gemini is a beautiful idea.
However, it works on the basis of mandatory-prohibition. The prohibition is: "You cannot track and exploit your site visitors". This philosophy is enforced 'remotely', by the creators of the Gemini protocol.
An identical end-result can be achieved in HTML, by choosing not to use hostile markup. However, with HTML the prohibition must be enforced 'locally', by the ethical-philosophical position of the website-designer.
The problem with the Gemini-protocol is that it introduces an attack vector: The Gemini 'browsers' themselves. The most popular one is not audited; has a huge code-base; and has relatively few eyes-on-it.
I'm not saying that Gemini protocol is a honey-trap for those trying to exit the surveillance-internet; but if I was a tech-giant / agency profiting from the surveillance-internet, I would definitely write browsers for the Gemini protocol and backdoor them.
As a former "Don't be evil" company, it would be of great interest to me who was trying to exit my 'web'; how; and why :)
Food for thought...
> You cannot track and exploit your site visitors
Despite the specification, there is such possibilities as TLS fingerprinting, URL tracking, although it does reduce much of the problems of WWW.
> The problem with the Gemini-protocol is that it introduces an attack vector: The Gemini 'browsers' themselves. The most popular one is not audited; has a huge code-base; and has relatively few eyes-on-it.
You do not have to use the most popular one (I don't use the most popular one); there are many others available as well, and the specification is made that you could hopefully make your own one if you like to do, too.
> if I was a tech-giant / agency profiting from the surveillance-internet, I would definitely write browsers for the Gemini protocol and backdoor them.
Nobody is required to use that specific implementation, and someone might find the backdoors, but it is possible.
> As a former "Don't be evil" company, it would be of great interest to me who was trying to exit my 'web'; how; and why :)
You do not necessarily need to write a new browser to check this; sometimes they already write public documents about these things, and there are many other ways to track it (e.g. by logging other things, by tracking browser extensions, etc).
The whole point of Gemini's simplicity and designed-in lack of evolution (through missing version numbers) is that you can write a fully featured client yourself, because the protocol surface is not that large once you leverage an existing TLS library.
the userbase for gemini is so miniscule, I can't imagine they could get enough data to want to even bother. Bit like trophy fishing in the puddle of rain runoff next to the stocked pond of monster bass.
Gemini for me has been such a breath of fresh air in contrast to 2025 Internet, with so many ads, grift and now AI slop.
Back when I first discovered Gemini, I wanted to create a space for people to have a voice without needing to run their own server, so I built Station (https://martinrue.com/station). I've been running it ever since.
Gemini in general, and specifically folk who use Station regularly, make it a friendly, throwback-to-the-90s vibe, and I still value it a lot.
Gemini the protocol is still a bit mysterious to me. Why not use plain HTTPS and just serve a new text/x.gemini MIME type? Or even serve plain old text/html and enforce no-JS-or-CSS in the Gemini client.
Part of the goals of making it so tiny, as far as I understand it, is that a normal person could reasonably implement the entire thing from server to client. Going full HTTPS and HTML is a bit of a lift for a single person in a short period of time
Because then it would be using HTTPS, and would not be isolated from the web in the way Gemini intends.
I like Gemini. My (anonymous) blog (gemlog) is posted there and has an http proxy, and is a no-brainer to maintain.
Once in a while I check Lagrange (Gemini "browser") for gemlogs I've subscribed to and catch up with what other anons are going through. It tends to be a lot more raw and persona-less than what I find on the web, which I appreciate. It's generally just cozy.
Does gemini have any concept of feeds or pub/sub?
I noted there were a few capsules that acted as a sort of hub for other peoples capsules. which suggested to me there was a way to automate it, and I might be able to make my own
These are some feeds and aggregators I have bookmarked
gemini://skyjake.fi/~Cosmos/view.gmi
gemini://warmedal.se/~antenna/
gemini://calcuode.com/gmisub-aggregate.gmi
gemini://gemini.circumlunar.space/capcom/
gemini://tinylogs.gmi.bacardi55.io/
gemini://sl1200.dystopic.world/juntaletras.gmi
Does gemini have any concept of feeds or pub/sub?
Yes: https://geminiprotocol.net/docs/companion/subscription.gmi
Many clients, including my favorite, Lagrange (https://gmi.skyjake.fi/lagrange/) support feed subscriptions.
Are SpaceWalk [1] or Moku Pona[2] what you're looking for?
1. https://tildegit.org/sloum/spacewalk
2. https://github.com/kensanata/moku-pona
I love the idea, but it's just to fringe to use for me. But I will say that I think the internet was far better before Google search really became strong, and before the corresponding massive increase in SEO spam.
"1.1.1 The dense, jargony answer for geeks in a hurry
Gemini is an application-level client-server internet protocol for the distribution of arbitrary files"
If I were one, I would consider that to have been buried.
This is just somebody's "finished" pet protocol (author did not allow anybody to give input). Narcissism we should not enable.
I will stick to gopher, as it is mature and much friendlier to low spec / retro machines.
The author very much did allow others to give input. The original protocol had single digit status codes, I was arguing for three digit codes, he compromised with two digit codes. It was my idea to include the full URL for requests, and for redirections. It's just that it wasn't easy, but he could be reasoned with. The only two hard lines Solderpunk had for the protocol was TLS, and single level lists (why, I don't know).
Gopher user there from texto-plano (and seldomly, SDF).
Gopher often sucks for 40x25 devices or mobile ones. Yes, word wrapping, but everyone uses the 72 char limit or even doesn't give a heck and I have to set my own $PAGER calling fmt, fold or par before less.
On TLS, you are right. But I've got to build BearSSL and some libreSSL for for Damn Small Linux. The 2.4 kernel one, were ALSA was a novely and DMIX was hard to set, the one you got with Debian Woody... with the bf24 at the LILO prompt.
So, if DSL can run some BearSSL based OpenSSL-lite client, a gemini client for it should be totally doable.
One issue I have with BearSSL is that it does not currently implement TLS 1.3, as far as I can tell.
That's not narcissism - it's just someone building something they enjoy and sharing it with the world. Do you have the same objections to fiction writers or songwriters?
It's totally fine to prefer gopher for its maturity (I'd vehemently disagree, but that's for another day) or compatibility with retro machines, but framing someone else's creative project as a character flaw is just rude.
I think Gemini is a step in the right direction for some things. I usually mention my "tersenet" ideas when I see Gemini. Now that we have the Gemini LLM and Claude etc. there is less excuse for me to not finish any real software demo for it. Maybe one these days I will make an actual client for part of it.
I think there is room for things like media and applications even on an idealized web. But they should not necessarily be combined along with information browsing and search into one thing.
https://github.com/runvnc/tersenet
> I think Gemini is a step in the right direction for some things.
I also think so, although I have criticisms of it too (e.g. mandatory TLS; I think optional (except files that require authentication for access) would be better), but nevertheless it can be used.
> I usually mention my "tersenet" ideas when I see Gemini
I have seen TerseNet, and I mentioned it in my "small web" document. I think it is good that media and programs are not loaded automatically, although there are other problems with TerseNet in my opinion, such as text being limited to 5K.
> I think there is room for things like media and applications even on an idealized web. But they should not necessarily be combined along with information browsing and search into one thing.
I agree, it is helpful, and they should be separated.
I also made up a protocol and file format specification, in order to deal with the criticisms of the other ones. In addition to avoiding many things, there is also adding things which would be useful, beyond what WWW and others might do. So, it is not strictly a subset of the functions of WWW, even though many things are deliberately avoided.