Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I first came across Gemini after making my own HTTP alternative TUI-over-the-wire protocol (uggly)[1].
Gemini has the same motives as I had when I started, but I didn't switch to it for all the same criticisms that are mentioned in the article (e.g. TOFU, no visualization support, no stream/data support, no cookies for login support, etc).
I'm really glad to see that the desire for a simpler protocol is still going strong though.
[1] - https://github.com/rendicott/uggly
Markdown has loads of bad design decisions for writing a parser... or being the (human) parser.
I've made an attempt to do better, it may be illuminating: https://github.com/civboot/cxt
I've built search engines, servers, clients, a Wayback machine, and other things in Gemini, so I have a better-than-average informed view of the protocol. Many of these observations are wrong or don't matter in practice. (Paraphrasing Daniel)
> Short-lived TLS connections bad!
Content served over Gemini doesn't cause a cascade of requests like HTML does. You don't download a page, close the connection, and immediately need to fetch something else. A subsequent request, if it happens, is dozens of seconds later.
> No TLS resumption
This is false. Many servers support TLS resumption, using the typical. Usually you just get this with the TLS library. or even use TLS/1.3 with 0-RTT resumption options. In fact, here is a service that tests if your client is using TLS resumption:
gemini://gemini.thegonz.net:1956/
> TLS client certificates (!) for keeping state between requests
This sounds odd to something who knows Client-side certs from HTTP. Think of them as unforgeable session identifiers that you the user are control in. Want the server to know who you are between requests, you client generates a cert and its hash is used to uniquely identify you. Someone rigged up a cool service where you can play Zork and other text adventure games, and the server know what game to send you to based on that certificate hash. Don't want it anymore? Delete the cert. It's like opt-in cookies.
In practice, very view parts of Gemini use Client-side certs (primarily forums). My latest crawls shown less than 0.01% of all URLs in Gemini space use a client-side cert.
> No inline images
This isn't a thing in practice. For most clients, when you click on a link to the image, they display the image inline. Here is Lagrange, perhaps the most popular client, displaying an image inline from a Wired article:
https://github.com/acidus99/NewsWaffle/raw/main/imgs/newswaf...
Oddly Daniel is taking a positive and framing it as a negative. What the positive here is is that Gemini clients don't automatically request anything unless you click it. So there is no way to have a tracking pixel or anything where you are automatically making a request to another, external system. That's a GOOD thing.
> URLs are ambiguous
In practice, this isn't an issue. I run a Wayback machine for Gemini (named Delorean) which has 3M URLs captured. The only odd/malformed URLS or content I've ever encountered are super super old servers, from late 2020 when the protocol was still being developed that send a tab instead of a space in the response line.
> Proxying can't work
This is false. It does! I built and run a Gemini-to-HTTP(s) proxy, lets you. It fetches HTTP(s) content. It converts HTML on the fly to gemtext, RSS into links, and proxies all other content. Duckling Proxy is another popular proxy.
gemini:/gemi.dev/stargate.gmi
> The Gemini protocol reeks of GOPHER and HTTP/0.9 vibes. Application protocol style anno mid 1990s with TLS on top. Designed to serve single small text documents from servers you have a relation to.
Yeah. Exactly. Why are using using italics like this is a bad thing?
> TOFU and scare questions about how certificates are stored in a multi-user system
They are stored just like any other data is stored in a multi-user system. Most client's use a dot directory in the user's home. I seriously have no idea why someone like Daniel thinks storing a the TLS fingerprints for a few thousand certificates is hard.
> I strongly suspect that many existing Gemini clients avoid this huge mess by simply not verifying the server certificates at all or by just storing the certificates temporarily in memory.
I have literally never encountered a client that doesn't verify server certificates. Clients aren't just storing them in memory temporarily. Personally my client stores them in a Sqlite database in a dot directory of the user's home folder.
Overall, I think Daniel is missing the point. Gemini isn't an HTTP replacement. These are systems that don't need to scale to solve the C1M problem, or even the C10K problem. I run some of the more popular services and a few hits per minute is a busy time for me. These are fun, hobbyist systems, playing with a protocol that isn't economically practical to commercialize and hence doesn't have to deal with ads, tracking, etc. Stop thinking about it so hard. It's just for fun.
> If you bothered writing a spec, it might as well be unambiguous, no?
Sure, people want unambiguous specs. However there is a list of literally dozens of working clients, servers, and libraries that were implemented based on the Gemini spec as is. Perhaps Daniels concerns are, in practice, not as important?
https://github.com/kr1sp1n/awesome-gemini#clients
I would also point out the hell that is the HTTP/1.0 and HTTP/1.1 specs, and that it took ~15 years for the HTTPbis group to remove all the contrary and ambiguous parts of it.
> His point is also to criticize the technical choices but that's fair game too.
Sure, but many of his criticizes are false. Full Stop. (servers and clients DO support TLS resumption. Proxying does work and there are multiple working examples, client's do server certificate validation)
Or don't make sense ("Gemini closes a TCP connection? HTTP figured out keeps-alives in 1996! This is bad design." HTTP has different access patterns. If Gemini had those access patterns it would be bad design. It doesn't)
https://github.com/makew0rld/amfora/issues/199