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.
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.
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.
It being too basic and rigid to the point of hostility towards anything but pure text is the entire point.
Even monks liked some illustrations (illumination) in their manuscripts. Gemini is closer to babylonian clay tablets delivered over TCP.
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.
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.
which subset?
the older html/http versions are older versions, not a subset of the modern html/http. afaik modern html/http doesn't have subsets.
>using a popular browser like Chrome
Gemini is created so that anyone would be able to write a Gemini browser in a couple of days. Or server.
I don't want "popular HTML browser" because I won't be able to write something like it in whole life.
Anyway...
_________________
/ /|
/ / |
/ Table / |
/ / |
/________________/ /||
| __________ | / ||
| | | || | | | ||
| | | || | | | ||
| | |_|/ | | |_|/
| | | | | |
|__|/ |__|/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.
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.
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.
"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.
No, that bit is the simple bit.
> 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*_`).
In summary, Markdown parsing is a clusterfuck.
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.
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.
>"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.
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.
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?
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.
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.
<html>
Lots of plain text
</html>
<h1> <h2> <h3>
<p>
<ul> and <li>
<a>
<blockquote>
<pre>
I think the gemini format is attempting to make it possible to basically render the document line by line.
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--?
Parsing speed, really? In this age?
It has its problems but its easy, widely adopted, with hundreds of tools, and simply way more capable than gemtext (which is simply very bad).
Parsing Markdown is fast enough.
But I agree MD isn't a good interchange format.
To me they look much the same.
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.
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?
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.
No markup syntax is straight up worse
I took my own stab at similar constraints: https://github.com/civboot/cxt
But as long as it scratches your itch and you're productive in it, that's what counts.
Then went on not understanding why people value Markdown, and do something entirely worse, without any good reason.
Gemini is Gopher with TLS and without the Gopher document types.
If you want protocol to be light and low on bandwidth, why would you not include at least the simplest of caching semantics ?
It is just bad design decision after bad design decision
Caching can be abused for tracking.
That's why both are solutions to the problems the Gemini project is trying to solve.
I've made an attempt to do better, it may be illuminating: https://github.com/civboot/cxt
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.
Gopher was interesting up until you used the web.
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.
https://news.ycombinator.com/item?id=8274870
https://blog.codinghorror.com/responsible-open-source-code-parenting/
https://blog.codinghorror.com/standard-markdown-is-now-common-markdown/
[0] - maybe underdelivering is the wrong word, but a mutual need was articulated and what was delivered was suboptimal
There's no place for Gemini.
It is a reasonable requirement in the 2020s.
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.
You don't need POST. You have queries (and many Gemini people use Titan as well).
It's not meant to replace http. Use Gemini for the things it's meant for and http for the things it does best.
(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.)
But I often browse Gemini pages, and many people have capsules that don't have web mirrors.
> 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/newswaffle-story.png
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.
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.
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.
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. 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)
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 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