💾 Archived View for gemini.leafstorm.org › en › gemlog › 2022-01-29-todo.gmi captured on 2024-02-05 at 09:33:03. Gemini links have been rewritten to link to archived content

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

My Gemini to-do list

To help me keep track of my current plans for my participation in Gemini, I have added a to-do list page to the gemlog.

📎 To-do list

My actual time to work on these projects is limited, which makes it important to focus. Right now it looks like I can spend about one evening each week, and a few hours on some Saturdays and Sundays. (Today is one of those Saturdays -- we had snow in Raleigh for the third week in a row, and my previous plans are cancelled.)

The first priority, ahead of the technical work, is writing. It's something I would like more practice in -- I get the chance to write at work often, but usually just reports on quantitative data, and I want to broaden my sphere. I also have a tendency to edit exhaustively until I think my writing is perfect... Writing my post about acceptance in response to ew0k took over two hours for barely five hundred words. I would like to practice to improve my editing speed, and also to become less perfectionist. Gemlogging is a good opportunity for this.

In addition to writing in English, I need more practice writing in German. I read extensively in German, and practice conversation for maybe an hour or two each week, but I don't have much opportunity to practice writing, and I probably imagine that I am better at it than I actually am.

On the technical side, I am very grateful for smol.pub, but it would be nice to have my own Gemini capsule -- first so I can write CGI scripts for fun, and second so I can test using Perez to upload files with Titan. The urge to write my own server entirely is strong, but it's probably not the most worthwhile use of my time. I'm looking forward to when skyjake releases GmCapsule.

skyjake's blog post about GmCapsule

An aside

While I'm talking about server software, it doesn't appear that there is a server with all of the following features:

Automatic TLS certificate management
Name-based (SNI) virtual hosting
MIME type overrides (like .meta files in Agate)
CGI scripting
Caching
IP rate limiting and generation of 44 SLOW DOWN responses
Other common security mitigations that may become necessary

Writing one's own Gemini server software is of course terrific fun, but it seems like the community would benefit from focusing on one or two servers that could implement these "frontend" features reliably. They could be used the way nginx is used in the HTTPS ecosystem, proxying to bespoke application servers that have less to worry about.

Another aside

One of the entries on my list is "write proposal for additional status codes." In analogy to the 31 permanent redirect status code, I think it could be useful to have a suite of status codes that indicate the degree to which requests are cacheable and/or repeatable. My ideas so far are:

20/30 - No special semantics. Repeating this request may or may not return the same content.
21/31 - Permanent response. Repeating this request will always return this content, regardless of a client certificate, with no side effects.
22/32 - Shareable response. Repeating this request in the near future without a client certificate will return the same content, with no side effects. (If the request had a client certificate, 22/32 indicate that no special content was served to you because of your certificate this request... but other client certificates may receive different content.) (The biggest issue with 22/32 is defining the cache lifetime.)
23/33 - Nonrepeatable request. Repeating this request will have side effects or return an error message, and the user may not expect it. Clients may wish to warn the user and ask for confirmation before repeating the request.

It would also be good to have a status code in the 10 family that indicates permanent prompt messages -- that would eliminate many unnecessary network round trips. But defining the semantics of that with client certificates could get complicated.

📅 January 29, 2022

📧 Email Matthew about this entry

📓 Flip to the table of contents

🔙 Close the notebook