The gemlog comment daemon

... in C! With _unix-composability_!

Initial writeup: 2024-08-29

I've written a fastcgi application that can make your gemlog more interactive by enabling users visiting your site to add comments.

In C?! What? Why?

Well, I have my reasons. Some of them are:

• I wanted to play with low-level sandboxing APIs (hint, hint...)
• I wanted to utilize low-level sandboxing APIs on multiple OS-ses
• I wanted to write portable code with low-level sandboxing APIs on OpenBSD and Linux
• I wanted to repeat myself here, obviously :b

Explicitly, my canonical choice would have been Rust, but I have decided against it. Mainly because Rust isn't well supported on OpenBSD. And because I wanted to refresh my C-knowledge! Libevent and everything. I didn't want to use something like rust-tokio to just setup some networking. That's just way too much considering what I am trying to achieve with gmlgcd.

And the result hardly depends on anything! gmlgcd only needs libevent (for portable, event-based networking), libconfuse (because I couldn't be bothered to write config-parsing from scratch) and optionally libbsd (if you are, beware: on linux; because there, strlcpy and strlcat are missing). (And meson for building, which depends on python and kinda messes with my argumentation here, but well, meson is really nice! I for sure won't use CMake or Make [_god forbid_] for C projects anymore.)

Why should I use this application, given that it is written in an unsafe language?

You are absolutely right with your concern. And I assure you, I am also concerned. But fear not! I can reduce your concerns. (Hopefully.) Consider this:

• gmlgcd will restrict itself, such that it only has write-access to two directories (one with a caveat, to which I will come back later) and it will drop privileges.
• I have written it in such a way that memory allocations (as possible leak causes) are reduced to a minimum.
• I have run it against valgrind to check for memory-leaks, while spamming it with comment requests.

Also, there is other functionality that is supposed to guard against idiots:

• Only comments from visitors that have a client-certificate setup will be allowed to comment.
• Any bogus requests or spam-attempts are rate-limited, based on client certificate, and IP.
• No comments including headers (lines starting with #) are allowed

Now, granted, this is some very basic ratelimiting. But after all, this is geminispace, so, are bots really a problem? (Future me will probably look at this line and facepalm...)

Unix-composability

Now, on the same train of thought that has departed from "Portable-C" city, and passed by "Dockerized-Dumbness" town, we reach the point that enabling comments for a given gemlog post is nothing more than just creating a file, and making it writeable for gmlgcd. That's it. And if at some point you don't like to receive more comments for a given post, disabling (but preserving existing) comments is just as easy as revoking write-permissions to that file. Now that's what I call _unix-composability_! :b

How can I use this magnificent software?

I'm glad you asked! Up until now, the code is not open-source, mainly because there are still minor things that I'd like to polish. Still, I provide you an outline on "requirements" for your setup:

• You will need a gemini server that supports FastCGI and sends the correct FCGI_PARAMS. I use gmid and it was mainly developed with gmid in mind.
• Given a gemlog at, lets say, /srv/gemini, you will need a dedicated comment directory, say, at /srv/gemini/comments.
• A given post, say, /srv/gemini/myblogpost.gmi will then only be commentable, if /srv/gemini/comments/myblogpost.gmi exists and is writeable.
• For adding comments, you should configure your gemini server to direct example.com/add-comment/myblogpost.gmi to gmlgcd. (In fact, that first component add-comment can be anything.)

Then, you might as well add some useful links to myblogpost.gmi:

=> /comments/myblogpost.gmi View comments
=> /add-comment/myblogpost.gmi Add comment

After a user enters a sane comment following a request to /add-comments/myblogpost.gmi, he will automatically receive a redirect to /comments/myblogpost.gmi to view his great creation.

Actually, if anyone feels like they are in a hurry, I'll probably release the source-code upon their request. The only thing I am still contemplating about is the LICENSE. I just can't decide between AGPL (true copyleft) or ISC (true freedom, similar to gmid).

Can you help me with this decision, and/or are you in a hurry? if yes ...

... add a comment ;)

actually, how am I supposed to pronounce this??

I have never said it out loudly, but I imagine it as "gemlog-cd" or "gimmlceedee". haha.

Cheers!

Home