💾 Archived View for rawtext.club › ~sloum › geminilist › 005769.gmi captured on 2024-03-21 at 16:37:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Mon Mar 1 02:48:38 GMT 2021
- - - - - - - - - - - - - - - - - - -
It was thus said that the Great Solderpunk once stated:
Howdy Geminauts,
Greetings and salutations, Geminauts.
It has become clear to me that for a variety of reasons I am no longer
able to effectively lead this process myself. Therefore, effective as
of the sending of this email, I am delegating decision-making authority
for finalising the spec to Sean Conner <sean at conman.org>.
I've been spending the day catching up on the list and thnking about whatneeds to be done. Stéphane Bortzmeyer suggested setting up an issue trackerat some place like Gitlab, and I've done just that. I set up tworepositories there:
https://gitlab.com/gemini-specification/protocol https://gitlab.com/gemini-specification/gemini-text
to track issues related to the protocol and the text format. I split themin two because it made sense to me---the issues of the protocol are largelyorthogonal to that of text/gemini and not everyone has interest in both. Abit long term is to split the Gemini specification into two along thoselines, so those that want to discuss content generation don't have to wadethrough technobabble of networks and ports and oh my!
I've created a few issues already, but gitlab is apparently having issuesof its own right now, so for now, the mailing list is still the place tobring these up. Anyway, while I'm here I might as well weigh in on some ofthe current proposals.
First up is favicon.txt. In my opinion, it does NOT violate the letter ofthe spec, given that it doesn't require any changes to the protocol ortext/gemini. It could be argued that it violates the spirit of the spec,but I am not willing to endorce nor condemn it. My decision would be thatclients can support it, but it MUST be disabled by default and require userintervention in some form to enable it. On the flip side, those who runGemini servers MAY configure their server to return "52 Gone" for requeststo "/facicon.txt" if they do not want to participate in such nonsense (thankGod I was able to convince Solderpunk to add this reponse code back in theday). Clients that receive a "52 Gone" for such a request SHOULD NOT makeanother request for it. But those who run Gemini servers SHOULD NOT expectto see no further requests from a given IP address---there might be severalpeople sharing an IP, or one user might be using multiple clients. Thewhole intent of serving up a "52 Gone" is to add said server to a list ofservers not to query. Yes, this is more of an "opt-out" than "opt-in"situation, but it's hard to opt in to a feature when it's distributed. Thiscan be extended to further requests of a similar nature should they come up[1]. I would like to ask Michael Lazar to please add these changes to hisfavicon.txt specification to let others know of the options available.
Second, alt-text for preformatted blocks. The original spec did not allowany text past the "```". It was later changed for reasons of accessibility,but intentionally left ambiguous for a consensus to form around it. I thinkdisallowing text on the closing "```" is too excessive and I will mostlikely rescind that decision to allow more options. But as for specifyingan actual format in the specification? No. Best practice, yes, but a solidconvention needs to arise first.
Third, meta data for text/gemini. Again, like alt-text for preformattedblocks, this isn't something for the specification. Again, it would be bestfor the community to define a convention first. My own opinion here is thatmeta data is always nice (Lord knows I have enough in my blog [2]) buthaving been through the "Sematic Web" era, not enough content creators careenough to actually do the work.
Fourth, I would like to state that newcomers to the mailing list might notbe aware of the history and context that Gemini was developed in, and thinkof Gemini as a "stripped down web" instead of the "souped up gopher" that itis. Please keep that in mind as new people make proposals, and instead of a"No" with no further conversation, say "No, because here's how you could doit" or "No, because we want a privacy-first stance". In other words,explain why the "no". Or, if nothing constructive comes to mind, don't sayanything and let the proposal die quietly.
-spc
[1] This concept will be added to the "Best Practices" document.
[2] Check the source for http://boston.conman.org/