I’ve basically given up on Gemini - granted, I was a vociferouscritic, then tried it out in the interest of fairness, and then lost interest for good.
If you’re interested, I can recommend the Lagrange browser (a very impressive project) and gemini://warmedal.se/~antenna/ as an aggregator of sorts. It’s a decent starting point for further exploration.
I admire many of the philosophical and aesthetic choices in Gemini, but I remain frustrated at the choice of requiring TLS. Writing a rudimentary Gemini client is only “simple” if you can rely upon an existing TLS implementation, an enormous external dependency which attaches a similar sort of “complexity ratchet” to the protocol as encrypted HTTP.
Nevertheless, many Gemini enthusiasts choose to make their capsules also accessible to gopherspace; the existence of Gemini seems to have greatly increased enthusiasm for the protocol it was most interested in updating!
There was (and to a degree, still is) attempts to bring TLS to gopher but it’s not as easy as running it over TLS. To address this, Solderpunk thought of a new protocol, similar in nature to gopher, but starting with TLS. There is a version of Gemini sans TLS known as Spartan [1] if you want it [2].
During my time with Gemini, I found two groups of people who wanted to remove TLS. Group 1 wanted it at least optional, because TLS was too complex to handle and no one could implement TLS by themselves [3]. The second group because TLS was too complex and should be replaced by some bespoke encryption system they just read about (or developed). [4] I always found it amusing that the two groups wanted to remove TLS for different reasons. It sounds like you are in the first group.
[1] It’s technically not Gemini sans TLS, but close enough.
[2] I dont’ think it’s as popular as Gemini though.
[3] Without realizing that most people don’t bother with implementing TCP by hand. And yes, there were a few people who felt that TCP should have been optional.
[4] One person actually did implement their own encryption system for Gemini, only to realize after the fact that it was a mistake to do so.
TCP has a fixed set of requirements. TLS incorporates an open-ended and ever-growing collection of cipher suites and relies upon regularly updated certificate data from trusted authorities to function.
Implementing TCP correctly by yourself is merely difficult, and it’s possible on quite humble microcontrollers. Implementing TLS correctly by yourself is a herculean task with a limitless unavoidable maintenance treadmill and comparatively quite demanding resource requirements. These types of dependencies are not the same.
Had TLS been optional for Gemini, then there would have been significant complaints that it should have been TLS-only from the start (a blog entry of mine made it to the Orange Site and half the conversation was about the lack of HTTPS my site had at the time). So there is no winning.
On TCP, I never said TCP was easier or harder than TLS, just that every design choice at the time was decried by someone somewhere. Also, TCP does change, it’s just that changes made to it are smaller, backwards compatible, and slower:
0007 Transmission Control Protocol (TCP). W. Eddy, Ed.. August 2022.
(Obsoletes RFC0793, RFC0879, RFC2873, RFC6093, RFC6429, RFC6528,
RFC6691) (Updates RFC1011, RFC1122, RFC5961) (Also RFC9293)
Note all the Obsolete RFCs there. And TCP is assumed to run on top of several other protocols (IP and Ethernet for instance)—how deep down the implementation rabbit hole do you want to go?
My final comment on this—just do it! Make the Gemini protocol without TLS and start pushing it. See how far it goes. My other major complaint about the development of Gemini (at the time) was the amount of talking going on, with no one bothering to try the things they were arguing for or against.
Yeah, I meant without the HTML. A reasonable markdown-like markup language with an unambiguous definition that multiple people can implement from the spec and get the same results. Something simpler, more regular, and more composable than CommonMark would appeal to me — I think djot without the HTML would be nice — but everybody knows markdown, there are multiple existing implementations, it’s an easier sell.
I wouldn’t recommend its continued use to many, but I would recommend everyone to try it and learn from it.
When I discovered it, I nearly immediately switched my blog to being Gemini-first (but with a transparent HTTP/HTML alternative front end). I still browse Antenna every few days. There’s an interesting community around Gemini where I have met people, went back to IRC, etc. It takes a certain kind of person to enjoy Gemini, but there are literally dozens of us having fun with Gemini.
(The other cool thing, you can do interesting things in Gemini without a lot of effort. And because it’s “new”, you have many chances of innovating, or delivering things that others use! It has this unique, small world charm.)
But yes, it’s very small, there’s not so much to do, and it has some technical issues (many of which cannot be solved because Gemini is intentionally locked). So in practice, most are not going to use it very much.
However!
Using Gemini expands your mind. In my particular case, it has reinforced my perception that the web is “broken”. In my head, the web is made of two very distinct things: content websites and web applications, with some spectrum in between, and a few variants.
I think we have mostly succeeded in making the web a universal platform, but while that’s a great achievement, it comes with problems.
To me, a major one is that to support applications, browsers have become such big monsters that even Microsoft has given up on maintaining a web browser. In practice, a single private company (Google) controls browsers.
This is not so much a problem for the web as an application platform (or at least, I think it’s nearly an inescapable problem for application platforms, so what can you do), but I think it’s terrible for content websites.
And modern content websites, well, suck. While I don’t think the ascetic approach of Gemini (deny all features!) is the ultimate approach, it shows the way. Gemini websites load instantly, could be extremely accessible (there are flaws in Gemini that prevent excellent accessibility, IMHO, but they are fixable), adapt to every device; small screens/big screens/no screens/touch/no touch… In some ways, browsing Gemini is much better than browsing a significant chunk of the content web.
Gemini is an eloquent demonstration that content websites could be infinitely better! I was already an ascetic/minimalist web developer, but I’m now even more so- and working with Gemini has made me learn about being more ascetic and minimalist.
I think it would be wonderful if everyone realized that a simpler content web would mean the Google stranglehold on browsers weakens significantly. You cannot browse a lot of the content web nowadays without a powerful browser. But you could browse most of it on Lynx if the content web adopted Gemini-like power. Many more parties would be able to develop browsers for the content web. It is not an easy maneuver, but I believe it can be done.
And well, people would still be free to develop Electron-like web applications that only work well on Chrome. But with more browsers being able to compete on the content web, there would be room for innovation and for overtaking Chrome. Faster loading pages, more usable experiences, etc. And (I’m being unrealistically hopeful here), perhaps people would enjoy their time on the content web more, and spend less time in Chrome.
I really like Gemini as a concept, but a couple of sticking points interfered with me staying involved with it:
I never found an easy to way publish to Gemini myself, or at least never got around to doing sufficient research to make my own Gemini capsule. Not having a way to participate makes it less fun, since “blogs are conversations”. I subscribed to some gemlogs and read passively for a while, but got bored.
There was some Gemini forum where you could log in with an “identity”, a locally stored “self-signed 2048-bit RSA certificate”. Lagrange (the prettiest Gemini client) encourages you to set an expiration date on this cert, or at least provides a field for doing so at creation time. I foolishly set an expiration date, and then discovered there was no way to replace or update your cert on the forum, you have to make a new account every time. The forum maintainer recommended not using a cert with an expiration date, but what happens if you lose the cert? AFAIK the forum software never dealt with this issue.
I’ve been thinking about treating the mTLS certs as MFA, and allowing people to use a username & password. You could even give them backup codes should they lose a cert (do to loss or expiry or whatever). It is nice that you can use mTLS so easily, but I do agree it has some edge cases for regular users (loss, multi-machine, &c).
I’m new to Gemini and sympathetic to its goals. I haven’t read all the documentation, but I get the sense Gemini aims to be technical solution to some problems we see with the web. But of course, many of these problems are rooted in to the economic incentives involved. I’d be interested to find critical writing that digs into the tough issues of trust, incentives, scaling (of community in particular), and monetization.
Of course it’s nice to build things from scratch and it sends a strong message which helps if you’re trying to start a movement. But to me something like the 1MB Club seems much more relevant to actual websites. If you want the web to be smaller, why don’t you make a small web?
I’ve basically given up on Gemini - granted, I was a vociferous critic, then tried it out in the interest of fairness, and then lost interest for good.
If you’re interested, I can recommend the Lagrange browser (a very impressive project) and gemini://warmedal.se/~antenna/ as an aggregator of sorts. It’s a decent starting point for further exploration.
Thanks for the links. The first two were posted to lobster before with quite a few comments
https://lobste.rs/s/vhlagb/why_gemini_is_not_my_favorite_internet https://lobste.rs/s/3lqpko
That is a fascinating discussion!
I admire many of the philosophical and aesthetic choices in Gemini, but I remain frustrated at the choice of requiring TLS. Writing a rudimentary Gemini client is only “simple” if you can rely upon an existing TLS implementation, an enormous external dependency which attaches a similar sort of “complexity ratchet” to the protocol as encrypted HTTP.
Nevertheless, many Gemini enthusiasts choose to make their capsules also accessible to gopherspace; the existence of Gemini seems to have greatly increased enthusiasm for the protocol it was most interested in updating!
There was (and to a degree, still is) attempts to bring TLS to gopher but it’s not as easy as running it over TLS. To address this, Solderpunk thought of a new protocol, similar in nature to gopher, but starting with TLS. There is a version of Gemini sans TLS known as Spartan [1] if you want it [2].
During my time with Gemini, I found two groups of people who wanted to remove TLS. Group 1 wanted it at least optional, because TLS was too complex to handle and no one could implement TLS by themselves [3]. The second group because TLS was too complex and should be replaced by some bespoke encryption system they just read about (or developed). [4] I always found it amusing that the two groups wanted to remove TLS for different reasons. It sounds like you are in the first group.
[1] It’s technically not Gemini sans TLS, but close enough.
[2] I dont’ think it’s as popular as Gemini though.
[3] Without realizing that most people don’t bother with implementing TCP by hand. And yes, there were a few people who felt that TCP should have been optional.
[4] One person actually did implement their own encryption system for Gemini, only to realize after the fact that it was a mistake to do so.
TCP has a fixed set of requirements. TLS incorporates an open-ended and ever-growing collection of cipher suites and relies upon regularly updated certificate data from trusted authorities to function.
Implementing TCP correctly by yourself is merely difficult, and it’s possible on quite humble microcontrollers. Implementing TLS correctly by yourself is a herculean task with a limitless unavoidable maintenance treadmill and comparatively quite demanding resource requirements. These types of dependencies are not the same.
Had TLS been optional for Gemini, then there would have been significant complaints that it should have been TLS-only from the start (a blog entry of mine made it to the Orange Site and half the conversation was about the lack of HTTPS my site had at the time). So there is no winning.
On TCP, I never said TCP was easier or harder than TLS, just that every design choice at the time was decried by someone somewhere. Also, TCP does change, it’s just that changes made to it are smaller, backwards compatible, and slower:
Note all the Obsolete RFCs there. And TCP is assumed to run on top of several other protocols (IP and Ethernet for instance)—how deep down the implementation rabbit hole do you want to go?
My final comment on this—just do it! Make the Gemini protocol without TLS and start pushing it. See how far it goes. My other major complaint about the development of Gemini (at the time) was the amount of talking going on, with no one bothering to try the things they were arguing for or against.
My ideal would be gemtext-over-http.
How about markdown over http? More palatable than gemtext and still an easy task to implement for one person.
That sounds good in the sense that you meant it, but technically markdown is a superset of HTML, so it’s not THAT implementable.
But get rid of the HTML part and I’m all for it.
Yeah, I meant without the HTML. A reasonable markdown-like markup language with an unambiguous definition that multiple people can implement from the spec and get the same results. Something simpler, more regular, and more composable than CommonMark would appeal to me — I think djot without the HTML would be nice — but everybody knows markdown, there are multiple existing implementations, it’s an easier sell.
I really like Gemini.
I wouldn’t recommend its continued use to many, but I would recommend everyone to try it and learn from it.
When I discovered it, I nearly immediately switched my blog to being Gemini-first (but with a transparent HTTP/HTML alternative front end). I still browse Antenna every few days. There’s an interesting community around Gemini where I have met people, went back to IRC, etc. It takes a certain kind of person to enjoy Gemini, but there are literally dozens of us having fun with Gemini.
(The other cool thing, you can do interesting things in Gemini without a lot of effort. And because it’s “new”, you have many chances of innovating, or delivering things that others use! It has this unique, small world charm.)
But yes, it’s very small, there’s not so much to do, and it has some technical issues (many of which cannot be solved because Gemini is intentionally locked). So in practice, most are not going to use it very much.
However!
Using Gemini expands your mind. In my particular case, it has reinforced my perception that the web is “broken”. In my head, the web is made of two very distinct things: content websites and web applications, with some spectrum in between, and a few variants.
I think we have mostly succeeded in making the web a universal platform, but while that’s a great achievement, it comes with problems.
To me, a major one is that to support applications, browsers have become such big monsters that even Microsoft has given up on maintaining a web browser. In practice, a single private company (Google) controls browsers.
This is not so much a problem for the web as an application platform (or at least, I think it’s nearly an inescapable problem for application platforms, so what can you do), but I think it’s terrible for content websites.
And modern content websites, well, suck. While I don’t think the ascetic approach of Gemini (deny all features!) is the ultimate approach, it shows the way. Gemini websites load instantly, could be extremely accessible (there are flaws in Gemini that prevent excellent accessibility, IMHO, but they are fixable), adapt to every device; small screens/big screens/no screens/touch/no touch… In some ways, browsing Gemini is much better than browsing a significant chunk of the content web.
Gemini is an eloquent demonstration that content websites could be infinitely better! I was already an ascetic/minimalist web developer, but I’m now even more so- and working with Gemini has made me learn about being more ascetic and minimalist.
I think it would be wonderful if everyone realized that a simpler content web would mean the Google stranglehold on browsers weakens significantly. You cannot browse a lot of the content web nowadays without a powerful browser. But you could browse most of it on Lynx if the content web adopted Gemini-like power. Many more parties would be able to develop browsers for the content web. It is not an easy maneuver, but I believe it can be done.
And well, people would still be free to develop Electron-like web applications that only work well on Chrome. But with more browsers being able to compete on the content web, there would be room for innovation and for overtaking Chrome. Faster loading pages, more usable experiences, etc. And (I’m being unrealistically hopeful here), perhaps people would enjoy their time on the content web more, and spend less time in Chrome.
I really like Gemini as a concept, but a couple of sticking points interfered with me staying involved with it:
Many tildes provide free Gemini hosting. Tildes are actually awesome, even if you are not interested in Gemini.
I’ve been thinking about treating the mTLS certs as MFA, and allowing people to use a username & password. You could even give them backup codes should they lose a cert (do to loss or expiry or whatever). It is nice that you can use mTLS so easily, but I do agree it has some edge cases for regular users (loss, multi-machine, &c).
I appreciate the notice that there is a Wikipedia page with some interesting citations I hadn’t seen before.
I know a non-tech guy who actually uses gemini: gemini://kwiecien.us/
I’m new to Gemini and sympathetic to its goals. I haven’t read all the documentation, but I get the sense Gemini aims to be technical solution to some problems we see with the web. But of course, many of these problems are rooted in to the economic incentives involved. I’d be interested to find critical writing that digs into the tough issues of trust, incentives, scaling (of community in particular), and monetization.
Gemini is far too complex, which is why I developed the Mercury protocol instead!
Introductory blog post: https://jfloren.net/b/2023/8/8/0
Spec: https://raw.githubusercontent.com/floren/mercury/refs/heads/master/SPEC
Of course it’s nice to build things from scratch and it sends a strong message which helps if you’re trying to start a movement. But to me something like the 1MB Club seems much more relevant to actual websites. If you want the web to be smaller, why don’t you make a small web?
It looks pretty lame and I love minimalism.