Gemini server

[ssb22]

Project/idea summary

Gemini is an experimental protocol that is 'heavier' than Gopher but lighter than the Web. It would be nice if the SRCF could support public_gemini in the same way that it supports public_gopher and public_html. Various servers are available for Gemini, but none of them have yet been made into Debian or Ubuntu packages, so making a Gemini server available on the SRCF would require us to compile from source and do our own security checks, but the Gemini protocol is supposed to be simple enough to make this feasible.

Motivation

Supporting the Gemini project by allowing SRCF members to create Gemini pages here.

Alternatives considered

It is currently possible for individuals who want to experiment in Gemini to ask for an account on one of the "tilde" servers like Ctrl-C Club (a DigitalOcean instance), but we don't know how long that will last. A Gemini server on the SRCF might have better long-term prospects.

[CMTC]

Sounds like a good idea to me. That said, I gather gopher is only kept around because it isn't yet too inconvenient to do so.

[edwinbalani]

gopher is only kept around because it isn't yet too inconvenient to do so

This is by and large true. We use pygopherd, which is slipping out of good availability in Ubuntu repositories on account of being written in Python 2. This same attitude generally applies to software that backs our less popular services and that can't be sourced from distro repos... if we can't run it with some assurance of built-in security then we shut it down. (See what happened to Timeout, even, although that was relatively popular.)

For what it's worth, we could switch to a different gopher server, or write our own -- like gemini the protocol is straightforward. It looks like there are some combined servers out there that support both.

That all said, I would like us to find a preferred way to deploy a small set of third-party software that isn't available in distro repos or a sensible repo from the software's own maintainer (which I emphasise because those have a good guarantee of receiving security patches promptly). I think this preferred approach should be Debian packages in apt repositories. A push to develop these deployment practices would encourage us to put together some automation like CI builds (for packages that we build ourselves), which in turn ought to allow us to do more with the dwindling time we have as volunteers -- a virtuous side effect. (Also in this category: the desire to write Ansible code that can put together our whole system.)

Historically it's been @mas90 and lately @rsa33 well-versed in any Debian package creation. We have a PPA of our own, put together by @mas90, and a few of his own PPAs we rely on, and then we're installing our Python libraries as packages, albeit from loose .deb builds that we make by hand. Perhaps a third-party gemini server that suits our needs would present a good exercise in building a package, installing it and configuring it. I think it'd be as approachable as it can be (which I say because Debian packaging isn't obvious the first time round in my opinion).