Returning to the WWW
... gemini only just wasn't meant to be.
Initial writeup: 2025-03-29
Everything wears off
Now, writing this kind of feels like a throwback to
where I elaborate on why I switched to the gemini ecosystem for my blog (gemlog) in the first place.
But I suppose I've changed my mind at the beginning of this year, as I am back on HTTP baby! This time though, my blog (gemlog) is available on both protocols. How can that be? Well, I wrote a gemtext-to-html converter, which is embedded into another FastCGI-server. Similar to
but different: as its handling HTTP, I call it
gmlghd
Yes, another terse name for a program. I love it. In any case, I wrote it, as I said, at the beginning of this year. And this blog was available under
since then, all the time. I was just too lazy to write a blogpost, lol. Kind of ironic, isn't it? I put so much time into raw-dogging C networking to have a nice, landlocked blogging framework that takes less than 5MB of RAM, to just then be fed up with blogging. But hey! I'm writing this blog post now =) (It just took... three months?)
What can I say, I kind of built many gimmicks into gmlghd. For example: trying to access URLs that do not exist will (when configured) redirect you to some other site, instead of just screaming 404 at you. Try it:
I promise, my environment file is not a hole-digging dog!
Give them scrapers something to feed on!
That's the main gimmick. Well, yeah, I kind of lied when I said "many". There are other useful features though!
Specifying your upstream gemlog
Ideally, you can run gmlghd on the same host as your gemlog root directory. That's also, what I consider, the main usecase of gmlghd, as it can just serve the files in that directory, while converting any .gmi to .html.
But there is more! You can actually specify some remote gemlog, on another host. Just keep in mind that for now, that feature is kind of experimental.
Multiple options exist: specify a full SNI, like "example.org", add the server certificate for more security, override SNI, and so on. Another cool thing I am kind of proud of, is that with a compatible upstream gemini server, in this case:
you can have requests to gmlghd be logged as requests to your gemini server. That is: the remote IPs of anyone accessing the HTTP-part of your blog will be logged in your gemini-server's log. Thats thanks to the PROXY procotol support in gmid, which I submitted. So gmid is probably the only server that will work with this.
That's actually another gimmick, if you ask me.
No CSS!
Yes! RAW HTML BABY!
Who likes to read that??
Probably noone. But I don't know any CSS! (I barely know any HTML...) So, anyone can write HTML or CSS, put that into a .html file and point gmlghd to it; it will then include it in the
tags of the document. In theory, you should be able to just put some drop-in-CSS, and your site should look good, as I (am trying my best to) use semantic HTML.Same goes for the element. The default advertises the gmlghd repository. :)
The HTTP version of this page has some really simple CSS that I found online, and copy-pasted into shape. So this should give you some idea.
Inline images
There is also support for inline images!!
Basically like the Lagrange smallweb browser. But of course, if you'd like your HTTP-converted gemlog to be as raw as possible, this can be disabled as well.
Documentation
Ha! There is barely any. Anyone needy enough can leave a comment on the gemini part of this site! That's actually another thing, I "designed" gmlghd to be "read-only". That is, you cannot, as of right now, input anything to a gemini site. And I don't think that's a problem because as everyone knows, the WWW is bad, and you should only open up the privilege of interaction to the geminauts!
Anyway, what I was trying to say is that right now, there is basically no documentation. The git repository comes with an example configuration file though, so that should get you started. And of course, there is a PKGBUILD on the AUR:
Put it behind nginx, and you're good!
It's free software!
Source