Wednesday, 2021-09-29

Setting up a Gemini server

I host my stuff on a Digital Ocean VPS.

I already have a webserver running, and my domain points to it.

I followed the steps in this instruction with some added wrinkles:

  • I could not get agate to start correctly, it would not bind to the ipv4 port 1965. After some desultory troubleshooting I used gemserv instead.
  • I didn’t bother compiling gemserv to use GGI, just static content.
  • The cert and key .pem files generated from the instructions worked great in gemserv
  • I used the systemd service example from the instructions, just replacing the call to agate with the call to gemserv

Update Wednesday, 2021-10-06

The main site can be reached on gemini://

I’ve set up a gemlog using Blosxom on gemini://

Update 2022-02-08

I’ve recently changed servers to Molly Brown due to this kerfuffle: gemini://

Tuesday, 2021-09-28

Gemini: the misaligned incentives

This is a followup to this post.

Since last time I took a dump long hard critical look at Gemini, I’ve decided to set up a server: gemini:// This article is reproduced there.

This has forced me to actually write gemtext, and boy do I not like it.

How does gemtext suck? Let me count the ways:

Long-ass lines

The Gemini protocol works line by line, so if you, like me, have been writing prose for time out of mind and have relied on your editor to justify paragraphs so the line isn’t just one long one… a client will probably mangle these, depending on the width it is using to display paragraphs. You get unbelievably ugly ragged borders.

But, the documentation says,

This means that, e.g. “dot point” lists or poems with deliberately short lines will be displayed correctly without the author having to do any extra work or the client having to be any smarter in order to recognise and handle that kind of content corectly. (sic!)

So, in order for simpler handling of “dot point” lists or poems, every author of gemtext will have to either live with long lines, or, more likely, introduce a software component before publishing to convert normally justified text paragraphs to long lines.

There’s another effect that I’ve noticed - boneheaded treatment of “text units” such as ISO dates and URIs. Most clients will happily treat a hyphen as an invitation to make a line break, regardless if this mangles dates or stuff like long command line options.

No inline links

I’ve already ranted about this, but now I’ve read some more Gemini content, and I still believe this is the greatest loss of Gemini. Hypertext is its own thing. Being able to be creative, or strict, or whimsical, or coherent with how you place your links or how you add the link text is a great expansion of human expression through text.

Gemini throws this away. It shows in most prose written in gemtext. The links are awkwardly placed, and the “placeholder” markers (such as numbers or brackets) to connect the text to the link below has not gelled to a standard.

No text markup (italics or bold)

Centuries of typographical refinement and tradition, thrown away for no good reason.

Note that this extents to newer conventions like code fragments, these are only supported as blocks, not inline.

What I don’t actively despise

The limit to 3 header levels and lack of numbered lists are personally ok for me.

Gemini culture prioritizes developers to a fault - but only up to a point

Just today I found a link about something called “favicon.txt” - essentially a single emoji that the console client I use (amfora) could use as a site identifier in its tabs.

In any normal project, this would have been seen as a cool feature, but in Gemini it is seen as a harbinger of the adtech apocalypse. The protocol is fixed in stone - for the stated reason that it should be easy for a normally talented developer to code a client over a weekend.

There’s nothing inherently wrong with this ambition, but it must be realized that it turns the usual developer/user dynamic on its head. Normally, the user’s requirements are interpreted by the developer, who makes concessions based on the user’s explicit and implicit actions. For example, the ubiquitous hashtag was something that emerged organically among Twitter’s users, and which the service incorporated as a new feature.

This makes economic sense as an expression of comparative advantage. Generally, users are prepared to “pay”[1] to not have to code something themselves. The developer can be seen a domain expert, prepared to spend time and resources to craft a product that appeals to the most users.

But Gemini states, as part of its explicit goals, that the protocol should be easy to develop for. This shifts the burden from the few (developers) to the many (users). To accommodate the ease of developers, users’ expression must be hobbled.

But it also means that developer’s natural curiosity has to be limited, lest they stray from the one true path of being able to easily develop a new client, should they wish to.

In short, Gemini is aligned towards a new developer, not invested in the ecosystem, to come in and develop software - but once they try to transition to a seasoned developer, or a user, the ecosystem denies them room to grow, to identify the pain points that have been overlooked by the original designers, or to take the project in a new direction.

As I’ve stated before, I’m sympathetic to the goals of Gemini, but the means are entirely inadequate to reach those goals. It’s an exercise in technical asceticism, dressed up in idealism.

Update Wednesday, 2021-09-29

This piece was submitted to and Hacker News and I think generated some interesting discussions. I urge the reader to peruse these to see where I am utterly incorrect above.

[1] this payment need not be monetary, as in the case of deep breath Free/Libre and Open Source Software.