NewsWaffle VS awesome-gemini

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)

There is a few gemini links on awsome-genini list.

I haven't tried them out, but usualy, awsome-* lists are good starting points.

https://github.com/kr1sp1n/awesome-gemini#services

oh I really like the concepts behind the Gemini protocol (https://github.com/kr1sp1n/awesome-gemini). Good to see a name drop here.

Firefox doesn't support opening Gemini links by default, but a range of clients capable of this exist, and, possibly, an addon as well. You would provide a certificate file to it as part of the configuration.

=> https://github.com/kr1sp1n/awesome-gemini * Repology has packages by operating system

You can also see if there is already built software on the awesome-gemini repository.

This tutorial will focus on using the simple Agate software to host your own Gemini capsule. There is a plethora of software to host your content, but I have found Agate to be simple and sufficient for my purposes. A collection of all things Gemini can be found here, which includes a list of server software. Let's get started.

For anyone looking for a fast way to dive into the "Gemini Space", I recommend you check out this list of resources (clients and whatnot): https://github.com/kr1sp1n/awesome-gemini.

Now, all you have to do left is to execute docker-compose up -d to start your server. After booting it up, navigate to your domain using a Gemini browser and you should see a nice page saying "Hello world!".