Tinylog RFC update - call for contribution
Posted on 2025-04-15
Edit: I did a mistake and instead of creating a merge request, I actually already pushed the new commit… I’ve linked the diff anyway and depending on the discussion I may revert some of it… But it does mean that there is no merge request to say to comment, instead, I’ve created an issue on codeberg for discussion.
As discussed in my previous gemlog about tinylogs, I’ve taken a bit of time to amend the tinylog RFC. There are 4 “real” changes: one major, two minor and one in the middle. And then some small wording modifications.
The TLDR; is simple: Major change:
- Date format, which is now more aligned with Gemini principle (read details below).
Minor changes:
- The level one title which was optional but is now mandatory, mainly because it makes more sense to have a level 1 title before level 2 for each tinylog entries, and because it could be used as a fallback when the “author” metadata (which is still optional) is not used.
- Description used to be acceptable before or after metadata, it must now be before metedata (again for parser simplicity).
“Middle” change:
- In case of writing a response to something (can be another tinylog, but can be a gemlog or even an http(s) link), the link is mandatory. The first “@” is mandatory for the author name, but the “@capsule.address” stay optional.
The main major change, as said, is around date, which for compatibility reasons with the early adopter of tinylogs were a bit too flexible… And GTL is even more flexible allowing so many different date and time format!
So I kept the Gemfeed date format YYYY-MM-DD and the usual time format HH:MM and removed the ability to add a timezone abbreviation to keep only the UTC related time, for 2 reasons:
- Gemini specs is built in a way to ensure simplicity for parsers, and timezone abbreviations makes the parsing harder. You then need a way to map these abbreviations with their values and then calculate the result. While not crazy complicated, it is, in my opinion, an unnecessary complexity.
- Even if the complexity in term of code isn’t high, timezone abbreviations are complicated because some can actually mean multiple things. CST is an example where it can mean “Central Standard Time” (UTC -06:00), “Cuba Standard Time (UTC -05:00)” and China Standard Time” (UTC +08:00) and is sometime used as a variant of ACST “Australian Central Standard Time” (UTC +09:30)
Regarding changes about the response format, I think it make things easier for reader (human, not tools). I can simply click to check where the orginal post where. It is a lot more helpful than the minimal version allowed before.
Let’s take the example:
Re: @john 2025-04-15 22:30
That isn’t clear at all! I don’t know which john the author is talking about because @capsule.address is not there either. And I prefer the link to be mandatory than the other capsule, because if I respond to someone using a capsule hosting services, the base address is shared with other, it doesn’t give me the full link.
And in any cases, even if I the @capsule.address is added, I still need to go to the capsule, then find the tinylog link and click. I don’t think it makes sense as it isn’t easy.
Forcing the link would even make simple parser easier: line starting with “=>”, then a space and anything but a space, then “re:”, then something else (the date and time).
I feel strongly about the date and title changes, but less about the two others. But I’m open to discuss for all 4 of them!
The full diff is on codeberg. To comment on these changes, you can:
- Comment on the merge request - edit: no merge request, so comment on issue #21 (link at the start of the post)
- Send me an email
- Write your own thoughts in Gemlog or tinylog (and possibly send me a link by email or ][gemini mention]])
I don’t expect a big war on those things as I believe a lot of tinylogs already aligned with those changes, but let me know your other ideas and thoughts.
Let me know your thoughts!