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)

using gitlab

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.

Using gitlab in both elinks in the terminal and with javascript disabled in qutebrowser (chromium)

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.

Okay, so after that big “fuck you” to anybody not using a graphical browser, you open up your non-chromium and non-firefox NetSurf browser. Every single page is blank except for a partially populated but broken sidebar. “Fuck you” again, you have to use the status quo and open up your mainstream browser. Since you're a sensible person you have javascript disabled by default (and the Gemini community is definitely the group most likely to have javascript disabled), and every single page is literally empty. Completely unnavigable, the sidebar is there but all pages are empty.

So after three big “fuck you”s you are forced to use your graphical browser with javascript enabled, and now you can actually read the full discussions. But you still can't participate at all because of course you need an account, a fourth “fuck you.” I didn't want to make an account, but I tried anyways and was literally unable to because gitlab got stuck endlessly running a “browser check,” the fifth and final “fuck you.” When I reached this point when they first announced the gitlab I gave up on actually contributing to the spec any more; at least until I decided to make this post right now.

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?).

whitespace after gemtext elements

gitlab discussion

I believe elements should have mandatory whitespace after them, and additional whitespace should be ignored:

# valid level one header
### valid level three header
#invalid header

* valid list line
*invalid* list line as it could be emphasis, as shown

=>//example.com/ewww-no-why-would-you-write-like-this invalid link line
=> //example.com/      <- the extra separating spaces should be stripped

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

fragments and gemtext

gitlab discussion

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)

gitlab discussion

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

gitlab discussion

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

gitlab discussion

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

gitlab discussion

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.

At most:

Consider this out-of-scope for the protocol itself. Recommend that UTF-8 text/gemini should not include a BOM.

tls close_notify

gitlab discussion

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.