↩ go back to index
comments on the wip gemini spec updates
october 10, 2021
I have some minor comments about the proposed clarifications in Sean Conner's draft updated specifications but don't have a gitlab account so I'm posting them here.
Repositories for the draft updated specifications
Sean Conner finalizing the spec announcement email (official web archives)
Sean Conner finalizing the spec announcement email (Gemini mirror)
First, we have to talk about the absolute galaxy brain decision by Stéphane Bortzmeyer and Sean Conner to use gitlab of all places for discuss the Gemini specification.
If you open any part of the repo or discussion in your terminal browser (elinks is my preferred one) you are greeted with a screenful of random navigation garbage, goody! The “skip to content” link is completely broken, I'm sure screen reader users love that even more than terminal browser users do. Once you've scrolled past the 325 screen-rows of useless junk (I counted) you finally get to the actual content—the issues/discussions list in this case. You get one of them open, the skip to content link remains broken so you scroll down manually, and you are greeted with… just the initial post. None of the discussion is visible, making it basically useless since you don't get anybody else's input or feedback and it's impossible to know what Sean Conner's decision on it was.
Oh yeah gitlab also uses cloudflare, woe betide the reader who dares use Tor or cares even a modicum about their privacy (nobody on Gemini cares about privacy, right?).
gitlab repo announcement Email (official web archives)
gitlab repo announcement email (Gemini mirror)
whitespace after gemtext elements
I believe elements should have mandatory whitespace after them, and additional whitespace should be ignored:
Additional space should be stripped rather than included in the link text, so the above link text is not “ <- the extra separating spaces should be stripped.”
fragments and gemtext
I think fragments being able to link to sections of a Gemtext document would be the second most valuable feature in Gemtext, right after links.
What if you wanted to reply to a specific point in this Gemlog post? Or link to § 5.4.3 in the Gemini Specification? Right now everyone is forced to scroll down and figure out where the mentioned section is themselves.
I propose a very simple heuristic that makes it very simple to implement, while not being fragile (i.e. simple numbered fragments break any time you add a new header):
1. Strip all leading and trailing whitespace from the header
2. Replace all whitespace in header with a hyphen (“-”).
3. If an existing header with the same name exists, either: 1) ignore this header, simplifies writing but disallows linking to later headers with the same name; or 2) append a hyphen with an incrementing integer, for instance “-1”, “-2”, “-3”, etc.
3. Encode non-URI-safe characters.
If a link with a fragment is followed and none of the headers on the document match the fragment, it should be ignored as if no fragment was included.
I would make fragments an optional part of the spec. If a client decides not to support them, it must ignore fragments and load the page as it ordinarily would.
fragments and the protocol (namely redirection)
Fragments should be entirely client side and should never be sent to the server as part of a request; servers should send a 59 response when receiving a request with a fragment.
Fragments should be preserved in redirects for the most common use-case of the article being moved to a different location where the fragment would still be valid; unless the server includes a fragment in the redirect, in which case the old fragment should be replaced.
queries and redirection
Like fragments, queries should be preserved in redirects unless the given redirect includes a new query, in which case the old query should be replaced.
1x response with an existing query string
I 100% agree that if a request with a query string gets a 1x response, any new input should overwrite the existing query. Appending with & is just a pathway to hellish unreadable URIs like on the web.
unicode byte order mark
This sounds like an author problem, if your tooling breaks shit it shouldn't everybody else's responsibility to fix it. If you're making something for non-tech people to use and they use bad editors that include a BOM, it should be your responsibility to remove it before publishing the document.
Consider this out-of-scope for the protocol itself. Recommend that UTF-8 text/gemini should not include a BOM.
TLS close_notify should be mandatory, although I haven't heard any arguments about that.
dumb new feature proposal: nested lists
From an old Flight Log post:
I want to air my “nice to haves” with gemini, specifically gemtext (stop getting angry, I know you have a few yourself). I don’t necessarily think these should be implemented, but it would be nice to have them.
The first one is nested lists. Using one, two, or three asterisks for three level deep lists would be nice, and doesn't break existing gemtext parsing. This wouldn't be an issue, except there’s no good way to represent a nested list for fancy clients that display bullets because the bullets are usually indented while the second level isn't, making it look weird.
It is perfectly in line with the rest of Gemtext's philosophy (and in fact mirrors headings exactly); and glancing at a few clients it would be exceptionally easy to implement. They would obviously be just as optional as level-one bullet points are. In fact, since the optional fancy line types are all standalone, all current clients would still be entirely spec-compliant if this was added since all they'd be doing is not supporting two optional line types.
Amfora's bullet list code, trivially modifiable to support nested lists
The zero lines of list handling in Bombadillo, the simplest modification ever!
↩ go back to index
add a comment!
view likes and comments
contact: alex [at] nytpu.com
-- Copyright © 2021 nytpu - CC BY-SA 4.0