Exporting the blog to Gemini
I've wanted to convert my blog to gemini for a while but I only found the time and energy to get it done this week. I've been working on a python script to convert my ~1600 blog posts to the gemini markup language. I wanted something that could run automatically, every 5min or so, checking to see if there are any new posts and automatically converting them to gemini. Ideally I wanted something I could set up and forget.
This site is written in Restructured Text (ReST) with some custom ReST directives. These days Markdown is more common as a lightweight markup language but I'm happy with ReST.
If you need to convert from one markup language to another the tool to use is pandoc. Pandoc understands a ton of different formats but not gemini. A few months ago I noticed someone had written a gemini plugin for pandoc so I thought it was time to get working on converting my site.
I wrote up a little script to walk through my sqlite3 database and extract entries, and a little parser to convert the custom directive I use for images to normal ReST but when I fed this to gemini plugin it did such a horrible job I started looking for alternatives. My second attempt was to convert from ReST to markdown and then use one of the standalone md2gemini converters but pandoc couldn't even convert my posts to markdown properly. I could update my scripts to generate HTML from ReST (basically what I do normally) and then use pandoc to convert this to gemini but it was getting ridiculous. The Gemini markup spec contains just five directives. My ReST contains 6 or 7. It wasn't much more work to just do the conversion myself.
Of course once I got started features started creeping in. Soon I was generating an index page with the last 20 blog entries, a page showing all 1500 posts, and an atom feed. I discovered a lot of bad writing and several edge cases where my conversion scripts were failing but now it's all working well.
If you're reading this on my http site (ha ha, who am I kidding? No-one reads this site) you can install a gemini browser to see the results. By design, there are a billion gemini clients but I can recommend the graphical browser lagrange. It's cross platform and somewhat polished. After getting that installed load up:
Once you've got a browser that understands gemini I recommend you check out CAPCOM to see if there's any other people out there talking about something you're interested in. Your mileage may vary, gemini is a niche app and everyone using it today fits comfortably into that niche.
Now it may seem like a lot of trouble to conver my site into a crippled markup language but I really like this explanation from the FAQ:
2.5 Why not just use a subset of HTTP and HTML?
Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites can track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they have to. Why not just build non-evil websites using the existing technology?
Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done.
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
My experience in geminispace has been nothing but pleasant. I'd still prefer a protocol that supports inline images but this is a breath of fresh air compared to the current commercial internet. Now that I support this very mainstream and popular format, I'm sure I will gain hundreds of thousands of new readers!
The infrequently updated blog.