đŸ Archived View for nytpu.com âș gemlog âș 2021-10-10.gmi captured on 2023-01-29 at 03:20:23. Gemini links have been rewritten to link to archived content
âŹ ïž Previous capture (2022-03-01)
âĄïž Next capture (2024-06-20)
-=-=-=-=-=-=-
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.
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?).
See Also:
gitlab repo announcement Email (official web archives)
gitlab repo announcement email (Gemini mirror)
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
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.â
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 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.
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.
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.
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 should be mandatory, although I haven't heard any arguments about that.
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.
See Also:
Amfora's bullet list code, trivially modifiable to support nested lists
The zero lines of list handling in Bombadillo, the simplest modification ever!
â