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 methods like session tickets. Usually you just get this with the TLS library. Many servers even support 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 someone who only 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 saying this in 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.
Daniel's post kind of reads kind of like the CEO of Coca-cola talking about how the supply chain and economics of a child's lemonade stand won't scale. Stop thinking about it so hard. It's just for fun.
