Site Migration and Updates 2023-11-07

My website has undergone significant changes in the last month or two, and I plan to continue to make more changes to it moving forward. I figured I’d write a post to outline what has changed and to act as a bit of an ‘update’ on what exactly is going on, especially as I haven’t posted here in over a year.

The most obvious change to the site that anybody who had viewed my site in the past will have noticed is the change of domain. The site previously was located at ‘’, which was a domain I had access to for free through GitHub Pages. I’ve now set up the old domain to redirect here, to the new ‘’, which I purchased recently. The biggest but probably least-obvious change to the site is one that is under-the-bonnet—the site is now entirely self-hosted1 on an OpenBSD VPS through Vultr. I’ve mucked around very superficially with OpenBSD in the past, and was curious about using it on a server. Debian GNU/Linux is of course the usual, almost traditional option for servers but I wanted something more interesting to play with and learn. I’m still learning how to use it of course, but in general it’s fairly straightforward to use, has fantastic documentation, and works beautifully as a server operating system.

I also went through the notoriously painful rigmarole of setting up my own mail server, that is now fully-functional and properly set up for the most part, and was something that I had always planned to learn and do myself at some point. Since around late 2019 I had been using ProtonMail as my primary e-mail provider, but over time had become increasingly suspicious of the service. There are some major annoyances with ProtonMail, namely when using it outside of the usual web-interface (as one typically does from a desktop)—one needs to set up some kind of ‘bridge’ software in order to use ProtonMail with a typical mail user agent, as obviously ProtonMail has their own layer built on top of the usual e-mail stack, to provide seamless and convenient encryption to it’s users. ProtonMail provides their own bridge (now also open-source) for their paid users only. Users who do not want to pay for the service, such as myself, have to either go without IMAP support, or resort to alternative/community bridge implementations such as hydroxide, which has it’s own host of issues, with occasional breakages and bugs due to internal API changes on ProtonMail’s end. I am especially grateful to finally be moving away from ProtonMail as the hydroxide project also appears to be slowly be dying, with suggestions by it’s author to remove IMAP support, due to a general lack of maintenance, and a supposed lack of purpose now that the official bridge is open-source, as circumventing ProtonMail’s pricing, which myself and likely a large number of end-users had used it for, is not at all recognised as being a goal of the project. When hydroxide does become unmaintained and die, my only option to access my ProtonMail mailbox would be through the official webmail client. Hence, although I have used ProtonMail and dealt with it’s many issues for a good while, I generally cannot see it as a viable e-mail solution for the long-term, as it brings in so much additional complexity and cruft that trying to use it as if it were a normal e-mail service necessitates that you build these convoluted and fragile systems that can break at any point, are inefficient, and generally annoying to work with. By running my own traditional mail server, I don’t have to deal with these problems anymore and I can finally just use a normal mail user agent like Mutt, and everything works as you’d expect it to. No more confusion and complications about PGP and signing too, as this is now handled where it is supposed to be handled—in the damn mail user agent.

I am also in the process of migrating my source code repositories that I care about from GitHub over to this server. I have no intentions to really host any new projects on GitHub or use GitHub for any other reason than to occasionally contribute to projects that happen to be hosted there. I generally dislike the GitHub workflow and it’s interface, and the idea of hosting my source code there when I can now easily (and more safely) just host here seems a little bizarre to me. I plan to have a simple web interface to my repositories. I initially was going to use cgit for this but am experimenting with and considering the simpler, static alternative stagit.

I was hit with a bit of inspiration recently and have various ideas of software projects that I would like to begin working on at some point. One such idea is a complete re-write of my ‘sr71’ terminal Gemini/Gopher client, which I wrote early on last year. I intended to make a post about this program in the past but never got around to doing so as I felt uncomfortable announcing it officially in the state it was in (due to potential inherent security flaws that are still unaddressed, and just general bugs in it). My interest in the text-based ‘small Internet’ (Gopher and Gemini) seems to have been recently renewed, despite the novelty of Gemini having clearly worn off in the last year or two, I do really like the idea of just browsing pure text documents online. I don’t intend to turn this site into a Gemini capsule or Gopherhole anytime soon, but I do think that trying to improve my client ‘sr71’ and even write some simple servers for these protocols would be interesting and quite fun, and it could be cool to run such servers here on this VPS (provided I am confident that they are secure enough).

1. The term “self-hosted” can be interpreted differently depending on who you ask—some interpret it to mean hosting a server on one’s own hardware on a network that they have physical access to, while others interpret it more broadly to include the case of hosting on a remote system (e.g. a VPS). I use the latter, broader definition in this article.