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.
> 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?
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. This had little impact on the raise of HTTP
> His point is also to criticize the technical choices but that's fair game too.
Sure, but many of his criticisms 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 TLS connection after each request? 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)
Stating that it's easy to develop clients and servers for Gemini is fine. But it's not how curl works. IF a feature is to be accepted, it will have to be maintained for a long time. In fact, it would not surprise me that curl's eventual implementation will be regarded as a sort of reference, simply because curl is such a well-regarded project. So it's really important to get this right.
And the spec is the only realistic thing to build on, because clients diverging from the spec have been threatened by blacklisting by other users (Amfora attempting to use emoji "favicons" for example led Drew Devault to threaten to ban the client from accessing his servers).
> 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.
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.
"a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec.
> There appears to not even be a support for a basic table
Given the number of Markdown table attempts I've seen over the years, I don't blame them for wanting to avoid that plague pit. Plus then rendering tables is another hellscape of torment.
>"a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec.
If your device don't have enough memory to parse the markdown document it can just display it. That's not an useful feature of a format. Hell, if it is really a problem use subset of it instead of using half, then inventing own, worse way, to add URLs into the text.
>> There appears to not even be a support for a basic table
>Given the number of Markdown table attempts I've seen over the years, I don't blame them for wanting to avoid that plague pit. Plus then rendering tables is another hellscape of torment.
If you don't we're back in ugly land of mono font manually setting it up, that's why I think that should be included in bare minimum of any markup format. But that's kinda beside the point as originally MD didn't had it either.
Gemtext has the pre formatted text fence that it specs as a mode-switch. Is that impossible with markdown? I think you could probably design every control symbol in markdown as a switch to “bold mode”, or “link content mode” and leave it at that. State machine style I guess?
> you could probably design every control symbol in markdown as a switch
You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there. But also! If you do something like `# Header _*bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes. But on a non-header line, `_*bold-italic\nstill bold-italic*_` works fine because EOL doesn't cancel them. But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_*with mismatched_* middle *_attributes*_`).
> You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there
Requiring like, a byte, for state is hardly a complex requirement.
> But also! If you do something like `# Header _bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes.
And an IF statement or two.
> But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_with mismatched_* middle _attributes_`).
Fair enough, but you can't expect to get correct output if you put wrong data in, you are trying to italicize it twice. If the interpreteation was "either * or _ turns italics on/off" you'd also have not what you expected.
My complaint about markdown here is really that there are 2 ways to make italics and 2 ways to make bold text. "Just" having * for bold and _ for italics would on top of making parsing easy also make it clearer. Less typing too.
> Requiring like, a byte, for state is hardly a complex requirement.
Add in table header and table cell to get to 128 states. You can probably get it above 256 quite easily. But the storage requirement isn't the point - it's that you have a complicated state machine where you can't just say "in-bold", "out-bold" as suggested because you also need "in-bold-whilst-italic", "in-bold-whilst-header", "in-bold-whilst-header-italic", etc. with the associated transitions.
Or you have a state machine for each attribute. But then `\n` can affect multiple of them at the same time and also require unwinding your state over a bunch of characters. You can say "this isn't beyond a competent developer", yes, but it is a long way from trivial to get correct.
> you are trying to italicize it twice.
Ah, HN mangled my example markdown. I should have remembered that happens.
> But why it isn't markdown? What does [Gemtext] add that markdown does not have?
I think that's the wrong question. Based on what I've read of Gemini, its focus is on simplification. The question the Gemini authors are interested in would be "What does Gemtext remove from Markdown?"
To which the most obvious answer, as you point out, is "HTML".
As for "Why not use markdown with the HTML elements taken out?" - does the world really need another markdown variant that's less capable than the current lowest common denominator?
I would argue it's actually a better idea to just call it a different format altogether, rather than attempting to fragment the markdown landscape even further. It also helps to forestall the question of "Why not add HTML support, like all other markdown renderers?" If adding HTML support is an anti-goal (which I believe it is) then making it so that adding that support requires someone to actually implement an HTML renderer puts up more of a barrier than leaving the door open for someone to just switch out the markdown engine for one that already does.
The right comparison is comparing Gemtext to Markdown. I don't think Solderpunk or other Gemini users have any complaint with Markdown in particular.
The biggest problem with Markdown is that the vast majority of Markdown libraries convert Markdown to HTML. These are of course useless to implementing a native client that isn't based on HTML. (In addition, the CommonMark test suite is concerned with defining the correct HTML to output for a given Markdown input.)
So while Gemtext is heavily inspired by Markdown, there's no reason to introduce a reliance on Markdown.
> 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 ?
Maybe an attempt to follow the philosophy of "avoid success at all costs", like the Haskell mantra?
>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?
There was some work on using RFC-3987 but it went nowhere as there was contention about how to handle international domain names---do you convert to puny code or not? Seriously, that's where it got hung up on.
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 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.
Some people hate what has become of the current thing so much that they want to throw all of it away. This is that.
The goal would be entirely achievable using your suggestion, but then you can't make something "simple" and "elegant".
Of course don't take my cynicism to mean that people shouldn't invent new things - they totally should, that's how we move forward. Mess around all you like. I just don't see it catching on. But I think that's not really the goal anyway.
Gemini makes sense when you realize it's the protocol equivalent of running off to join an anarcho-primitivist commune or ascetic monastery, a technical solution to an emotional problem (disgust with the web and modern capitalist society.)
It being too basic and rigid to the point of hostility towards anything but pure text is the entire point.
> This means anyone still using a popular browser like Chrome can visit your sites
I think this would be seen as more of a drawback than a feature. If you're trying to build a tight-knit little hobbyist community, random people popping in and complaining that "these pages are boring, where are all the images?!" isn't helpful.
Given that there are microblogging (gemini://station.martinrue.com/), reddit with optional git connection to allow for issue tracking (gemini://geminispace.org/), it seems you're wrong.
> 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.
Just make sure it never ends up in a security critical context. Various larger companies already got screwed over when their front end code did not detect the size of a http message the exact same way their backed code did.
That's not what alternative means. A passenger train is an alternative to a bus, but you can't drive a train on a freeway. "Alternative" in no way implies "feature parity". Getting addicted to meth and dying in a shootout with the police is an alternative to completing a medical degree and retiring to the Poconos, but they do not fill similar functions.
To be fair, I think it's pretty reasonable to say that walking 50 km isn't competition to taking a bus, but just an alternative. To be competition, it would have to be a _good_ alternative...
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.
The standard answer to this is that there's too many variants.
I think it should be a thing anyway. If Blink, Webkit and Firefox have compatible implementations there can be some sort of de facto standard and it will be fine for a number of actually useful things, even if it's not perfectly defined to pocket protector standards.
Markdown does have a MIME type, as defined in RFC-7763 and RFC-7764. Markdown was rejected from Gemini for being too complex. "text/gemini" can be parsed line by line, which is why it was defined the way it was.
What if browsers had a default stylesheet that doesn't suck? The fact that twitter bootstrap had to exist at all should embarrass browser vendors. If people could write their html like motherfuckingwebsite and trust the browser to make it look decent, the web would be a much better place.
That would be nice, but unfortunately improving the default styles now would break an ungodly number of things. Cat's out of the bag now, people rely on the crappy defaults (save for the minor differences between browsers).
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.
I think you just misunderstand the point. A lot of criticism of Gemini seems to make the assumption that it's intended to replace HTTP and that it's badly thought through for that use. In fact, I think it basically came from a niche group of Gopher hobbyist users who wanted to fix a few longstanding annoyances with Gopher. They wanted something that anybody could write a client or server for as a fun little weekend project, not something that requires end-to-end 3rd-party-verified proxiable SSL security.
Why not? Why is it necessary to use existing approaches, even if they add a lot of incidental complexity? What does it hurt you that Gemini has their own custom markup language that's different than Markdown? You can set up your own little Markdown HTTP server, they're not stopping you.
> In fact, I think it basically came from a niche group of Gopher hobbyist users who wanted to fix a few longstanding annoyances with Gopher.
To me Gemini looks like it was made by people that fetishized the idea of Gopher after reading about without ever have actually used it.
Gopher was not about reading documents, it was a way to map to resources. Those resources might be files or other servers. It was an improvement over FTP since gophermaps (menus) could be customized and link to servers rather than just files.
You could abuse information messages in a gophermap to make a readable document but it wasn't part of the RFC. You also had to make some terminal width assumptions because there wasn't a good way to control text reflow.
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.
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.
Gemtext seems to be more like wanting to be an online typewriter. Back when typewriters were used to write documents, there was one typeface and font, and no hyperlinks or images. To reference other documents you could use footnotes or a bibliography. Margins and line spacing (except maybe for block-quotes) were fixed. A lot of useful information was communicated in this format, but it does seem a bit too austere today.
That’s a good analogy, that does seem to be the guiding aesthetic they’re going for.
It’s austere but I can see why people like it if they’re really into writing as this raw “doesn’t need anything else” medium. I like my silly little pictures and syntax highlighted code samples though.
Yes that's true, I'll amend my comment to say that there's nothing about HTML that prevents you from writing in this austere styling if that's all you want to do. Quickly scanning the gemtext intro, it looks like you have headings (three levels), links (but not inline), lists, blockquotes, and preformatted text. That's it. So with these tags you're there:
<h1> <h2> <h3>
<p>
<ul> and <li>
<a>
<blockquote>
<pre>
Granted gemtext markup is slightly more terse, but it would hardly matter in practice.
Oh that’s a good point! I guess things like bold markers reaching over multiple lines does complicate parsing somewhat if you had to find the paired delimitators. But considering that Gemtext considers the pre formatted text block that starts and ends with backticks to be a “mode switch” I don’t see why you couldn’t consider spec-ing a sort of state-machine markdown. (Maybe that’s already the current understanding of it!)
If you leave off the ending * then everything till the last line will be bold, for example.
That’s gemtext though.
Mandatory TLS on the gem protocol makes most of this moot IMO. It’s 10x harder to view a gemtext document in a gemini browser. What simplicity did we gain with markdown--?
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.
I have a blog focussed on small entries (tweet length) consisting of Markdown in a fortune file format, that renders +10k items in about 5 seconds. Using Perl.
Your 10k items are probably only 2MB. Spending 5s to parse a 2MB text file is very slow, even for Perl. If you are distributing your file to users, that's 5s for each one of them. If you convert it to html and distribute the html file, your user will spend 1s in parsing, tops. This is exactly why I said Markdown makes a very bad interchange format.
Nah, it's 10K items spread over 45 files, 7.5M in total, and the blog engine generates monthly pages etc. Note that I've not bothered with any optimization, I re-render all content after adding one new item.
Except I prefer Markdown for the looks and how widespread it is.
I was a Wikipedia contributor for many years before Markdown came along, and I think Markdown has a better flavor for hyperlinks. "[link text](url)", "[link text][footnote] + [footnote]: url" are just great. I write like this even without any expectation of rendering it as anything but plaintext.
Years ago I read a well-reasoned comparison of a handful of markup languages and the author made a strong case for Creole (which I had never heard of before or since. I use markdown just like everybody else. ;)
Unfortunately, I can't remember the arguments and I've never been able to find that article again.
So I can't tell you why it's better. But try it and see what you think?
I already evaluated Creole and prefer Markdown. I also prefer reStructured Text over Creole.
Searching for comparative reviews, I’ve found five, neither of which recommended Creole for any particular reason.
My main point of review is how to make local links:
When I use Markdown, it’s either in my Obsidian notes which actually have a wiki-style [[link]] syntax (not standard for Markdown), or it’s in a git repository where local links means a link to a relative file path.
The latter is more portable, whereas wiki-style namespaces assume one homogenous knowledge base, which makes distributing documents more difficult.
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.
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
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?
TLS assures that nobody can tamper with the payload during transit. And while there's no POST, you can still post limited amount of data, which the linked article talked about.
Gemtext is a hyperlink format, Gopher is plain text. And some formatting takes you a long way.
HTML cannot easily be read in TUIs and needs layout engines only billion dollar companies can maintain.
Self signed != inherently insecure. If you have the public key, verified it, and you want to make sure that you're getting content directly from the server, you can do just that. It's just not got a chain of trust with root certs that are built into the browser.
My point is how do you get the public key if you can't trust what has been published? You can't trust the gemini site, you'd have to use another protocol, such as HTTPS signed by a CA in order to verify the public key you are being given was actually signed by the author and not someone in the middle rewriting the authors gemini content.
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:
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.
No, but browsing the web with w3m isn't much different than browsing gemini with amfora. And with xterm*colorMode:false set, of course. The web can be a lot worse than gemini, but that's the modern web for you.
(Yes, I know your http log says that this browser is "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 8.0; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MS-RTC LM 8)"; it is not. It is rather amusing to see what sites break because of this.)
I use Gemini with Lagrange, a Gemini GUI browser, as often as I use a normal web browser or RSS reader to read content. But I enjoy it much more. I'm a less-is-more-person, so it's a good fit for me.
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.