💾 Archived View for gemini.xangelo.ca › posts › gemini-intro › index.gmi captured on 2022-04-28 at 17:29:48. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
→ Older: Dungeon Generation in Roguelikes
For the last few months now I've started embracing my weird love for text and text-related user interfaces. From email to irc, I'm moving more and more of my social interactions away from traditional websites/apps and over to my terminal. A big part of this move is a step back from 3rd party applications to things that I have a bit more control over - but there are many reasons.
The hard part is that you need to find alternatives to a lot of traditional apps that you have come to rely on. For some things (email for example) it's very easy. For others, like web browsers, it's basically impossible. There are things like lynx [1] that you can utilize, but it's just not the same. So many websites now days are designed around the fact that the user is going to have a full GUI browser. And, honestly, that's a very reasonable expectation.
But I still found myself looking for an alternative. And I found Gemini.
Gemini [2] is an alternative to the HTTP protocol. It's definitely not going to replace HTTP, nor does it want to. Instead it aims to operate alongside. It's a very stripped down subset of markdown to enable easy implementations of parsing. A lot of the complexity of modern browser systems is around parsing HTML/CSS effectively and gemini just does away with that whole idea.
This means that documents in Gemini are very light-weight, and are readable without any parsing. You could just read the raw text that makes up a gemini doc (called gemtext) and be just fine. Any styling choices are entirely up to the renderer (browser mostly) and are irrelevant to the document itself. There is no way to view images in-line, there is no JS, there is nothing but text.
I really recommend you check out the gemini home page and do a bit of reading up on it.
Since gemini is a completely different protocol you can't access it with a regular web-browser that deals in HTTP. Instead you have to find an alternative browser that deals with the gemini:// [3] protocol. There are numerous [4] owing to the simplicitly of the parser implementation. The one I've been using most is a terminal based one called amfora [5], but if you're looking for something graphical I highly recommend Lagrange [6] which is wonderful.
Obviously this is just a browser, so you need to go somewhere. I recommend starting at geminispace.info [7].
One thing I should caution you - don't expect a full replacement for what you consider "the internet". Gemini is very simplistic and focuses on ease of content consumption. It doesn't make content creation hard, but because of the focus on content itself, "interactions" are minimal. Some capsules (the gemini equivalent of a website) have "comment" sections, which harken back to the guestbooks of the 90s.
The thing that attracts me to Gemini is the same thing that attracts me to most projects: putting data privacy/ownership above all else.
Getting technical, Gemini foces TLS connections. Nothing is transmitted un-encrypted. It also brings to the forefront client certificates in SSL. The original spec for certs already supports this and it's crazy that it never took off. It honestly resolves the whole account identification/password problem in a really neat way.
This is, I think, one of my favourite features of gemini. SSL certs have two sides, and most people are only familiar with one. Servers generate certs to identify themselves. But since anyone can just generate a cert, there is really no way of knowing that the server you are connecting to is who they say they are. That is, I can generate a cert for duckduckgo.com, and you would have no way of knowing I'm NOT the actual owner of that site. One way that we currently resolve this problem is "Certificate Authorities".
Certificate Authorities (CA) are just a collection of companies that at SOME POINT were declared trustworthy. You had no say in that process, and despite numerous hacks of the CAs, they're still considered "trustworthy". You pay these companies to certify that you are who you say you are. There are various levels of "validation" that you can do, but the end goal is that your browser trusts a bunch of these CAs. When they see a cert from your website signed by a CA, they trust it.
Don't get me wrong, trust in certs is a hard problem to solve and one that has been around for a long time.
Gemini utilizies the idea of "Trust on First Use (TOFU)". The idea is similar to how ssh manages your known hosts. The first time you visit a site in gemini that provides you a key, you just believe that they are who they say they are and record the key/site pair. Next time you visit, they simply match the cert recieved with what they have stored.
This is naive. The rational is, once you connect to a site you'll won't be able to connect to anyone else impersonating that site unless you forget the original key/site mapping. Of course, the reverse is also true -> if you connect to a site that is already impersonating a different one, you'll need to forget the original mapping before you can navigate to the actual site.
On the server side, it definitely feels a bit weird. But this works wonderfully for the client!
As a user, you can generate a single certificate that's YOU. You can then provide the public key for that cert to the server to identify it as you. If the server implements TOFU (which is how every authentication system ever works) then you are mapped to that cert on that server. Going to another server? Provide the same signature. Nothing to remember. You just need to keep your private key safe.
The "certification generation" part is the tricky part and is why this never caught on for authentication on the web. But in Gemini, which is currentyly a more technical audience, it's a bit more feasible as a solution. What it means is, as a user, I can generate a single "account" and reuse it everywhere.
I'm interested enough in Gemini to put some time into modifying my website to output docs in gemtext so that I can serve my site over gemini as well as http. There are a few steps here (including getting off github pages so that both domains can be served over the xangelo.ca root) but that's ok.
The first thing I had to do was figure out how to get my content into gemtext. The easiest way was just to utilize hugo and add a new gemini output. There are a couple resources on this, but the two that were the most helpful were this article by Sylvain Durand [8] and this one by Wouter Groenveld [9]. I won't re-hash what these are but the final configurations for my site can be found here:
I'm including them because I mostly cannibalized Wouter/Sylvain's docs. Wouter made the decision to get off Gemini due to the earlyness of the protocol (it is very early) and as such dropped the original config links that he had up. I just went through git history and found them and made a few tweaks and put them up in my repo.
At the moment I'm mostly doing what Wouter is - a "build" on my site involves me generating some hugo and usign scp to move it over to my gemini server. I'm then running agate [13] a bit manually while testing. This command just starts agate, tells it where my content folder is located, the addresses to bind to, and the hostname and language.
Agate will happily generate the keys for you on first run, or you can provide them yourself.
./agate.x86_64-unknown-linux-gnu --content ./gemini/ --addr [::]:1965 --addr 0.0.0.0:1965 --hostname gemini.xangelo.ca --lang en-US ``` For now, scp is fine - but I'll probably just set up a gemini submodule/repo and deploy that to my server instead. That way I don't have to worry too much about transferring the entirety of the site. ## Conclusion Overall, I'm pretty excited about Gemini. The ease of getting into the ecosystem as a consumer and publisher is amazing. There are some awesome projects to really ease that gap. But there's also plenty of room for growth and a small enough community that you can get involved in. The best place to get into it is gemini space [14]. I think the thing that excites me most about it is just the fact that there's such a big focus on privacy and small contributors. I think that's something that's missing from the web today, that we used to have at some point. --- ## References => https://lynx.invisible-island.net/ [1] lynx (https://lynx.invisible-island.net/) => https://gemini.circumlunar.space [2] Gemini (https://gemini.circumlunar.space) => gemini:// [3] gemini:// (gemini://) => https://gemini.circumlunar.space/software/ [4] numerous (https://gemini.circumlunar.space/software/) => https://github.com/makeworld-the-better-one/amfora [5] amfora (https://github.com/makeworld-the-better-one/amfora) => https://gmi.skyjake.fi/lagrange/ [6] Lagrange (https://gmi.skyjake.fi/lagrange/) => gemini://geminispace.info [7] geminispace.info (gemini://geminispace.info) => https://sylvaindurand.org/gemini-and-hugo/ [8] this article by Sylvain Durand (https://sylvaindurand.org/gemini-and-hugo/) => https://brainbaking.com/post/2021/04/using-hugo-to-launch-a-gemini-capsule/ [9] this one by Wouter Groenveld (https://brainbaking.com/post/2021/04/using-hugo-to-launch-a-gemini-capsule/) => https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/config.toml#L36 [10] config.toml (https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/config.toml#L36) => https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/layouts/index.gmi [11] index.gmi (https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/layouts/index.gmi) => https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/layouts/_default/single.gmi [12] single.gmi (https://github.com/AngeloR/xangelo.ca/blob/88c61cd88bd2228dc7f2e46871f5e5ea6e2fcfdc/layouts/_default/single.gmi) => https://github.com/mbrubeck/agate [13] agate (https://github.com/mbrubeck/agate) => gemini://gemini.circumlunar.space [14] gemini space (gemini://gemini.circumlunar.space) ---