💾 Archived View for gemini.abiscuola.com › gemlog › 2023 › 07 › 27 › who-need-a-cms-anyway.gmi captured on 2024-02-05 at 09:26:37. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Who need a CMS, anyway?

E-mail to the rescue! I believe others already did something similar.

The gemini protocol is fine and dandy. However, it doesn't, directly, support the upload of resources, making it non-trivial to create new content in an easy and portable fashion.

I was thinking for a while how to solve this problem for myself, given that, until today, I used to just store my gemini articles in a fossil repository, with a touch of "make" to build the capsule and it's web counterpart. This approach has some disadvantages:

It depends on a bunch of installed tools for developers (fossil, make, etc.).
It requires you to, for sure, be in front of a computer to publish an article, or to make any change (no portability).

Looking at the gemini landscape in particular, the only solution seems to be to implement the titan protocol.

The titan protocol.

However, I really, really did not want to write yet-another-daemon, or change gmnxd to handle this specific case. Not convinced, I started from the base, writing down the following requirements:

The solution must be device agnostic (being able to write from the phone, my pc, a tablet or even a guest computer).
At a minimun, it must be able to handle the publishing of an article and the upload of related resources (files, images, etc.).
Publishing a gemlog, should automatically mean that the web counterpart is generated.
In general, I must NOT need to directly login into a machine for a shell or whatever.
Write the less amount of code possible and leverage the existing infrastructure.
If possible, do not run another service!
No need to fiddle with paths directly. Write, push a button and see the magic happen.

After some heavy thinking, I understood that, what I needed, was something similar to a mailing list manager, but for my gemini capsule. Leveraging SMTP would let me to use any device where I have an e-mail account for my domain setted-up. In the end, e-mail clients are everywhere. Mapping my desiderata to an e-mail was quite easy then:

The user part of the destination e-mail addresses, identifies one of my capsules.
Commands: they are defined in the subject, in a key:value format (i.e. new:My new article creates a new gemlog with that title).
In the e-mail body, the text/plain part represents the gemtext content, text/html is discarded.
E-mail attachments, generally of type application/octet-stream, are additional resources that must be uploaded with an article (images, files, and whatnot).

My idea was to leverage, potentially, whatever e-mail client du-jour to publish an article whenever I wanted. In essence, whatever tool I would have written, needed to be able to take an e-mail, extract it's subject and destination and parse the MIME part in it's body. And that's exactly what I did, by writing a small custom MDA (Mail Delivery Agent).

An MDA is nothing more than a program that receives a full e-mail message in it's standard input. The MDA I wrote is composed by two parts, a shell script driving the majority of the automation and a TCL script leveraging the mime package to extract all the mime parts from the e-mail body.

The mime package

The steps are:

E-mail is received and stored by the MDA in a temporary file.
The command is extracted from the "Subject" header.
If the command is to create a new article, a directory, if non-existent, is created for the current day (path/YYYY/MM/DD format).
The title is extracted from the subject also.
The e-mail body is parsed and all the mime parts are saved in related files.
The gemtext is put in the right directory and the file properly named, along the other attachments that were present in the e-mail.
Gemtext converted to HTML through gmi2html and the same process is done the the WWW site.
Indexes for the blogs of both the versions (Gemini and WWW) are updated.

In the end, I implemented the following commands so far:

New article publishing.
Updating of an existing article.
Uploading of a generic file.
Deleting of a resource.

And everything is done for both the gemini and WWW versions of the site.

Security

To avoid potential issue with site hijackers, two things were modified in the opensmtpd configuration: a specific rule for the new MDA was put into place permitting only to a specific e-mail address to write to the gemini addresses. And that same rule action adds the authentication informations to the "Received" headers. This way I can, in the MDA, check if the e-mail was sent from a specific, authenticated account, discarding anything non-authenticated.

How does it works, in practice?

Well, better than expected. Leveraging the whole E-mail ecosystem (from the clients, to the SMTP protocol) on top of my automation, makes everything smooth. Combined with the fact that I have an IMAP server, it means that I can have my articles saved as "drafts", or, by putting myself in CC, manage the "revisions" by leveraging the threading capabilities of any e-mail client. I'm still exploring how to leverage this whole e-mail thing more, but it's already good enough to have a simple client to write, attach pictures and what not and with a push of a button, have your article published.

P.S.: No, I will not publish the code. It's tailored to my needs and hacked together. I'm not proud of it's quality.

In the end, Bananas!

bananas.jpg

If you want to know more, feel free to contact me in private, or on IRC, or the fediverse.

Enjoy!