In developing Haphaestus the sites which gives me the most trouble to support are the silos creatives feel expected to publish on. As such it is in my vested interest to question the value of these silos, leading me to self-hosting our own codeforge.
I’m renting a small Debian Xen-supervised VM from Rimu Hosting which I can feel free to share with other collaborators (though it does incur a small ongoing cost I’m minimizing). Upon which I’m running a Maddy email server, Snikket XMPP server, & SourceHut codeforge. Spamboxes aside, its never been a better time to self-host your own communications!
I’ve deployed a handful of sites, with their own domains, for each of Rhapsode & Haphaestus as well the overarching Argonaut Constellation. These are statically hosted by nginx (I personally like the config language) & secured by Let’s Encrypt Certbot, with more dynamic bits like this very blog generated via Jekyll before being uploaded.
The idea is that the browsers would have their own sites to serve as a front-face, and link interested developers to the over-arching project.
Maddy is a new email server written in Go with, as much as possible (some additional DNS configuration required), excellent defaults. New accounts can be registered, & IMAP inboxes assigned to them, with a couple of commandline programs. Once installed it pretty-much works out-of-the-box with your favourite email client! Even if I found Thunderbird infers the wrong username…
Snikket is a nontrivial Docker-packaging of the Prosody XMPP server with a web-UI & “official” clients. Simply running the docker image & making sure any existing webserver (if any) are forwarding requests to it gives you a working standards-based invite-only chat server with videocalling! Some subdomains do need to be set up for it.
I’m striving to embrace long-established open standard federated communication channels. Ones that operate outside the browser in a choice of native clients, so I’m not tempted to get Haphaestus to support them.
I wanted a codeforge which would take minimal effort for Haphaestus to render legibly. I wanted something I could easily fork to explore new browser features in. I wanted something invite-only which didn’t require people to log-in to contribute. I wanted something lightweight that could grow with my needs. SourceHut fits this bill!
SourceHut is an email-centric suite of software-project management webservices written in Python Flask & Go, including OAuth single-signon, with a cleaned-up CGit aesthetic. Under the hood these share the same webframework abstractions, mostly to hook various modules up to a single [INI] config file. It uses practically no JavaScript, though the markup whilst semantic is very much from the pre-CSS3 Grid Twitter Bootstrap era. Not my codestyle, but could be much worse & ultimately just requires me to support FlexBox.
I had some trouble installing SourceHut, my VM was too small to install from source, & until I upgraded to Debian Bullseye/Sid I couldn’t use the official packages. I was surprised how effortless that upgrade was! At which point I could use said official SourceHut Apt repositories, at least until I fork my own variations. However these packages still requires a fair amount of configuration to hook the pieces together, & making sure permissions were set correctly frequently tripped me up. And not all of those misconfigurations were picked up until I actually tried to use these…
To start I had to install the OAuth server “SourceHut Meta”, though presumably other OAuth servers could’ve been made to work. This took the most extensive configuration setting crypto-keys, branding, & desired registration flow (invite-only) whilst hooking up to eMail (via Maddy), Redis, Postgres, I skipped S3-compatible, & HTTP (via nginx) under a new subdomain. Whilst ensuring the seperate “API server” was running successfuly, accessible to the HTML UI server.
Once I had a way to authenticate into them I could deploy an access-controlled git web UI & an issue-tracker. Both of which needed OAuth credentials, a Postgres databases, & Redis for webhooks. Also the issue tracker can be hooked up to an emailserver so you can email its subdomain to open & comment on issues without signing up. Thankfully Maddy is a capable enough emailserver that I could forward SourceHut Todo its mail! Interestingly SourceHut Todo issue trackers don’t have to be associated with specific projects & public browsing can be disabled per-tracker. This can be very useful for e.g. security vulnerabilities reporting!
Maybe someday I’ll deploy a mailinglist server too… The other microservices SourceHut offers me to self-host don’t look that important for now…
To help ensure a more diverse range of potential collaborators feels comfortable contributing to the Argonaut projects ensuring it works better across a broader range of cultures, I drafted a code-of-conduct to be attached to any public forums like issue trackers. Since SourceHut supports Markdown in its descriptions I can place this code-of-conduct where I personally feel it’s more appropriate & clear.
This code of conduct is based on Django’s, an excellently-run project, lightly editted to refer to our projects, avoid inferring that we’re larger than we currently are, avoid promising actions we cannot offer at this stage, & address some additional inclusivity concerns we noticed.
I am aware that the real test will be when we have to, sooner-or-later, enforce our code-of-conduct. Hopefully by having an explicit one & a confidential issue tracker in place, it will be later!
I deployed my own communications server & codeforge so that the technology used to manage the Argonaut Constellation could be used to test it. And (once forked) test proposed new features in HTML/CSS! Following long-established open standards the Maddy, Snikket, & SourceHut projects were perfect for this.
I wanted to challenge the notion that all projects needed to be on the same service for the sake of discovery and ease of contribution. Because it is these sorts of silos which gives me the most trouble to support. Heck, it was never the case that all opensource projects were on a single service. Only a large minority of the projects powering your GNU/Linux terminal or your freedesktop operate on GitHub.
I hope this new infrastructure can serve The Argonaut Constellation well, and grow with its needs!