💾 Archived View for lonelysilo.ca › journal › 2021-03-15.gmi captured on 2021-12-17 at 13:26:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
235fb31e17f44cf4aa1b741050f4850282efe22c
I'm new here, very new. I first discovered Gemini about two weeks ago.
Gemini ticks alot of boxes for me. I have been an avid Go and Plan 9 user and developer for several years, which means that I like simplicity in computing. Gemini is a very simple protocol and file format eschewing much of the baggage being dragged around with everything to do with The Web, from HTTP all the way up the ever growing stack.
It embraces the idea of using text as the default form of information exchange on the net. Text is clean, small and about as future-proof of a format that we have on these digital computers. Plain text doesn't hide anything from the user. What you see is truly what is there. The sheer variety of tools that work with text ensures a vibrant ecosystem.
While the definition of plain text has been enhanced with UTF-8 (Unicode) encoding, which opens so many doors (multi-lingual, mathematical symbols, emojies), there are some things that are better served with other formats: images, videos, music. That's why you can hyperlink those things from some bit of text that explains their context. The Gemini protocol and URL's will link them if you want. Otherwise, if they are more suited to another protocol because of some special considerations such as size, you can link to those too using a different protocol.
The Gemini file format doesn't permit you to do all of the things that you can in HTML, nor even Markdown. What you lose in functionality you gain in freedom. The freedom to choose from a wider selection of tools. I admit that it is a bit of a shock at first going from site to site in Lagrange or Castor and finding that the Gemini sites don't have wildly different aesthetics. They all kind of look the same except for the information they convey. I have mixed feelings about that. Maybe I've become too dependent on the unique flashiness of each website I use on a daily basis? On the other hand, I know that I was once able to absorb information that looked much the same in books or in decades past on the Internet.
I really like the idea of not hiding the content of the text for a number of reasons. HTML browsers hide way too much of what's going on in a page to the detriment of the user, such as malicious links, or even code on the page. It leads to unintended consequences and lack of transparency for the user. Also, this is how you get gigantic web sites.
The trouble is not hiding anything is that you end up having to put markup to do useful things, like adding hyperlinks. Gemini chose not to allow you to put links inside your paragraph, because hyperlinks can become long and interfere with the flow of the text. So, they decided to let you put the links at the bottom of the paragraph or at the end of the document where they can consume an entire line if they need to be. Relating the link to the bit of text that refers to it is left as a convention with square braces that names the link of interest. Markdown let you do this as well, but it's not common because most users of markdown are more interested in the way it looks in their web browser where the URL's of the links are hidden. It turns out that hiding links let websites generate truly disgusting URL's for many years. I think that exposing them will improve overall hyperlink cleanliness.
Gemini does't try to be ubiquitous. The text format is not going to allow you to publish magazine-like glossy sites. It's not going to be able to support video conferences and playing multimedia games. Those are best left to other software , formats and protocols. Gemini tries its best to give you the escape hatches to get there with the hyperlinks with URL's and the ability to serve up files with other media types and that should probably be enough. You'll notice that there's no support for PUT/POST in the Gemini protocol, which means that mutating resources is left for the most part to some other protocol. Maybe sftp, http or even 9p will someday fill the mutation gap.
I wonder if Gemini could do somthing to better facilitate the mutation hand-off though. Initially, I thought that Gemini should have learned to support REST modes right away to avoid the mistake that The Web made where people couldn't easily make changes to web pages, giving birth to the concept of a Wiki. It might be possible to build some kind of "Edit URL" concept into the Gemini protocol or even establish such a convention in the page itself. The latter fits better with my preference to avoid hiding things.
It feels like there needs to be some kind of meta-protocol for Gemini and others so that they can work together better for hand-off situations like above. Another one has to do with identity management for both server and client. In a world of multi-protocol servers there probably should be a single certificate that it uses for a particular host name. It's the same for the client. If I'm going to be establishing an identity to use with a particular server(s) the Gemini client, web browser, sftp, etc. should all probably use it (or not) with that server.
It's clear the Gemini has taken an opinionated, but pragmatic approach. There are some areas where I wonder if that is the right choice. One is the use of TLS/X509 for secure communication and identity management. Another is the use of URL's, retaining the terrible encoding sequences (%20 for spaces). I understand that for interoperability URL's are a good way to do this for many protocols, but not all. Plan 9, for example has a completely different notation for ports, protocols and links that is arguably better in many ways. But, perhaps we can be pragmatic about this and find some kind of better ground.
I could propose that URL encoding sequences be removed entirely for Gemini hyperlinks in favour of either Unicode (IRI) and even allow spaces in them. You might ask how we might do this. Well, it turns out that formats, such as Turtle that makes heavy uses of IRI's, have ways of handling the spaces. The IRI's are fenced in between angle brackets so that the beginning and end of the link is parsable. So, Gemini could require either a newline after a link line or a ' -' to separate the URL for the metadata and then there can be spaces! Of course, it probably makes sense to discourage spaces in URL's for the most part, but that can be left up to the community to establish such a convention for friendlier hyperlinks.
Another area that I feel is a bit too pragmatic is the borrowing of media types from The Web. On the one hand, the Gemini spec encourages the use of file extensions, such as .gmi. But, on the other hand the media type of a resource is required and baked into the protocol. I've always felt that media types and any kind of content negotiation is way too heavy weight for what it needs to be. Why can't we use simple file extensions. Some may say that they don't account for compound file types, but then Unix has had .tar.gz for a long time, it's just that Windows couldn't do those until fairly recently. Let's stop the media type madness and just go back to regular file extensions. They work across different OSes, protocols. In fact, a Gemini server could already use them for polymorphic resources today. An able server could generate a PDF of a gemini page if the request has a .pdf file extension or serve the regular content if the .gmi extension is used.