This 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 ‘mikejzx.github.io’, 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 ‘skec.site’, 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 have their own layer built on top of the usual e-mail stack, to provide seamless and convenient encryption to their users. ProtonMail provide 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, must 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 (other than upgrading to a paid plan and using the official bridge software) would be to use the official webmail client, that I dislike. 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 (and do) break at any point, are inefficient, and are annoying to work with overall. By operating my own traditional mail server, I don’t have to deal with these problems anymore and I can finally just use a normal (good) 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 will add that the purported benefits of ‘seamless end-to-end encryption’ in ProtonMail are in practice quite meaningless for the most part, as for this to work at all in a convenient fashion it requires that ProtonMail be used a homogeneous e-mail provider among communicators (friends, colleagues, conspirators, and whatnot). The majority of people whom you might contact that would accept encrypted e-mail often don’t even use an encrypted e-mail service like ProtonMail, but rather instead simply have their own PGP keys that they offer to the public (as I do on my homepage). The reason this is so, is because logically PGP should be used when some kind of layer of security is desired with a message—it is dumb to try and build an e-mail system on top of PGP like ProtonMail does, because PGP was designed to be built on top of e-mail. Trying to use PGP through a slow, clunky webpage, in an e-mail service for which traditional PGP encryption and signing support appears to have been slapped on as an afterthought can be quite frustrating and if anything would deter people from using encrypted e-mail, rather than encourage them. Using PGP locally when available makes much more sense, and gives the user much more (very much necessary) control over how their e-mail will be sent, and is generally massively more flexible than the ProtonMail approach. I find that it is simply better to just accept that e-mail is inherently insecure to begin with and that it hence would be wise to not use it at all for highly sensitive communications. There is little reason to use an e-mail service that markets itself as being secure when it in reality is no more secure, and offers less control, for also a greater price than a traditional self-hosted mail server, which is not only literally just as secure (particularly if you take the ‘offline’ approach that I do, in which mail is downloaded and removed off the server immediately upon retrieval), but is drastically more liberating to it’s administrator/users.
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. |