I think Gemini proponents who think Daniel is missing the point, or that he should not overthink this so much as it's just for fun, are the ones missing the point.

Daniel is not saying that is a wrong thing. He is saying that he has a PR to review and would need a clearer spec for this and gives his opinion on how it can be improved. His opinion is interesting because he is a long time spec user and writer.

One commenter says that it's like the coca cola boss criticizing a competitor, but curl implements a lot of protocols. He probably doesn't care.

It's for fun, granted, but if you want curl to implement your fun project, part of the fun becomes doing things properly. If you bothered writing a spec, it might as well be unambiguous, no? Not that I think the point of Gemini is to be fun, mind you. I think it's a strongly political movement advocating for minimalism. I do believe it's a worthy cause.

His point is also to criticize the technical choices but that's fair game too. Again, his opinions as someone who has a lot of experience in the field are interesting too. Should I implement such a protocol now, I would definitely get back to this article to make sure I'm paying attention to the right things and making the right tradeoffs for my use case.

I overall think the Gemini community should take Daniel's input as a good contribution to their ecosystem. He took time to sit down and consider Gemini seriously. Several times.

Now he finds gemtext pages ugly, it's his opinion expressed on his personal blog, it's not particularly interesting and this opinion is not particularly related to his expertise. It's also not worth discussing with logical arguments since it's taste. Now there's still a point that can be made from this: if many people find Gemini ugly, including someone used to deal with RFCs daily, that means it will stay small. And that it's in the end, not an adequate answer for widespread minimalism it could have been and which is a goal that seems worth pursuing.

> Gemini documents certainly are never visually very attractive

As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client chooses. If most clients render text in an unattractive way, that's not a fault of the format. And I mean, I don't think plaintext is ugly.

Re: URL discussion

The author interprets "URL needs be UTF-8 encoded" as meaning that any escape codes in the URL need to use UTF-8. I interpreted that as meaning that the URL string as a whole should be UTF-8 encoded. In the author's example where there's a "%C5 in the URL", I'd just encode "%", "C", and "5" according to UTF-8. Maybe it goes without saying that the URL-line doesn't use UTF-16; but I think Solderpunk included it to be clear.

The high-level criticism, which is that Gemini's specification is too loose and vague, seems very, very convincing, even if the specifics aren't.

In a subtle way, this is a significant hurdle for any competitors to the HTTP world. They have to overcome 30 years of technical debate and refinement as ambiguities have been hammered down.

I too am nostalgic for a simpler web, and also an increasingly of the view that the modern web was a severe wrong turn for software engineering and computing generally. I also run my own gopherd and httpd servers. Despite the severe shortcomings of Gopher as a protocol in 2023, I simply cannot understand much of the design rationale behind Gemini.

Markdown is not a well-defined standard and is arguably no easier to parse than basic HTML 1.0. HTML can easily be rendered as text in a style not dissimilar to raw markdown if required.

The decision to enforce the use of TLS means that rolling your own client is less trivial than had it been optional. It also cuts out a big chunk of the hobbyist market who are most likely to be interested in a small, lightweight protocol. Support for Gemini will therefore be limited to systems with maintained TLS libraries. At the end of the day, anyone sniffing your Gemini traffic is going to be able to see the host you’re accessing - whilst TLS will preventable them knowing which specific page you’re reading, they will be aware of the set of pages you could be reading.

Instead, I am focussing my attention on building small, light web-pages that have completely optional CSS, are pure HTML without cookies or JavaScript and work in browsers modern or ancient. There’s a plethora of great browsers that can access it, from Lynx and Netscape running on a Solaris 8 machine to Chrome on my work PC. Servers are ample and well-tested.

And a good chunk of my website is text (rendered in Groff) to boot.

It’s 95% of the Gemini experience with 5% of the effort and 1000% more reach.

What if... Markdown was its own MIME type and browsers rendered it with a default stylesheet? :thinking_emoji:

This protocol looks like someone didn't exactly know how HTTP worked, and more importantly, from where the bloat came from, then tried to do something too simple.

Then went on not understanding why people value Markdown, and do something entirely worse, without any good reason.

Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.

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

I'm from the telnet generation. It's sad that Gemini got so popular while underdelivering [0] or missing the mark in some areas. That makes me sad because even if a project came along to 'do things right', I don't even have the bandwidth to adopt another protocol I'll hardly use, and then invest the time to build content and gather links.

[0] - maybe underdelivering is the wrong word, but a mutual need was articulated and what was delivered was suboptimal

People writing negative things about Gemini who haven't actually used it should start by reading the Gemini FAQ: https://gemini.circumlunar.space/docs/faq.gmi

It's not meant to replace http. Use Gemini for the things it's meant for and http for the things it does best.

It would be great if Gemini supported gzip/brotli compression, e.g. by decoding media type: `text/gemini; encoding=gzip`

Unpopular opinion: Gemini is Gopher done wrong. There is no need for a TLS layer in a protocol that won't let you POST, and there is nothing Gemini can do that Gopher(+) could not, except that it features "some" formatting - and then again, why not just stick with HTML?

There's no place for Gemini.

I love the idea of Gemini, but I feel like you could do the same thing, but better, with git and plaintext or markdown, maybe make a specialized client for browsing/rendering these git pages. "Gemini" as a protocol and name is just there for the community to nucleate around.

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.

does anybody actually use Gemini exclusively, or is it just like Gopher where everybody ends up hosting a HTTP proxy anyway?

URL discussion: This is exactly one of the author's points. The wording in the spec is too ambiguous. Different people reading it are interpreting it differently. No human language is really 100% unambiguous, but better technical writing here could increase clarity dramatically.

> As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client chooses. If most clients render text in an unattractive way, that's not a fault of the format. And I mean, I don't think plaintext is ugly.

Okay? But why it isn't markdown? What does it add that markdown does not have ?

It is just taking few things from markdown but changing enough that markdown interpreter won't work. What's the point of that?. Different for sake of being different ?

I can understand say removing any support from HTML elements in markdown if you want to make something entirely new, but the changes are just entirely pointless and not make it more readable.

There appears to not even be a support for a basic table, while calling itself "rich document" format

But the cherry on cake gotta be this part of paragraph:

> You may have noticed that gemini supports links to other protocols (the above example includes a web link, beginning with `https`, and a gemini link, beginning with `gemini`).

The author is using `the markdown code/monospace font` backticks from markdown, in document describing this shitty format, where they are not implemented, out of habit of using them in markdown.

UTF-8: how does that view mesh with

>This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986

^ that defines the percent encoding scheme.

About the only way I can think of is if Gemini URLs are a superset, and don't need to use percent encoding... but that means ambiguity when someone hands you a percent-encoded URL. Did they mean %C5 or %C5?

Lagrange makes Gemini pages look quite attractive in my opinion.

https://gmi.skyjake.fi/lagrange/

I agree. I think a lot of the problem can be solved with discipline rather than a new spec entirely. If HTTP offers features that are offensive or unwanted, simply don't use those features. Make an HTTP server and client that only implement a subset of HTTP. Then use a subset of HTML, or another content type entirely.

This means anyone still using a popular browser like Chrome can visit your sites, but people using a more limited client can as well. It also means you still get to lean on the 30 years of technical refinement rather than reinventing many wheels.

Gemini isn't a competitor to HTML, it's an alternative.

Gemtext is weird, it’s hyper-focused on a very specific form of text publishing. It’s not trying to be “old internet” featuring the creative freedom of its users, it’s just text content and that’s it. Not even inline links or images! Which I personally think makes it a bad format for the old-internet mainstay of “website about one specific interest of mine”.

I run a little capsule but I find myself with not much to do because I’m really not interested in writing long blog posts. I made a crappy HN reader over gem, it’s not very usable predictably haha

I still think HTML is the ideal creative-indy-internet format.

The problem with markdown, as I understand it, is that it's not possible to correctly render without reading the entire document.

I think the gemini format is attempting to make it possible to basically render the document line by line.

No, Markdown is a format for authoring HTML. It makes a very bad interchange format because the it leaves too much ambiguity in parsing. Also, parsing speed of Markdown is much slower than the parsing speed of a strictly conforming XML file.

Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)

Markdown is pretty bad for a lot of use-cases, like embedding data into text or using data to format text.

I took my own stab at similar constraints: https://github.com/civboot/cxt