[announce] Delegation of responsibility for spec finalisation

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 what
needs to be done.  Stéphane Bortzmeyer suggested setting up an issue tracker
at some place like Gitlab, and I've done just that.  I set up two
repositories 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 them
in two because it made sense to me---the issues of the protocol are largely
orthogonal to that of text/gemini and not everyone has interest in both.  A
bit long term is to split the Gemini specification into two along those
lines, so those that want to discuss content generation don't have to wade
through technobabble of networks and ports and oh my!  

  I've created a few issues already, but gitlab is apparently having issues
of its own right now, so for now, the mailing list is still the place to
bring these up.  Anyway, while I'm here I might as well weigh in on some of
the current proposals.

  First up is favicon.txt.  In my opinion, it does NOT violate the letter of
the spec, given that it doesn't require any changes to the protocol or
text/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 that
clients can support it, but it MUST be disabled by default and require user
intervention in some form to enable it.  On the flip side, those who run
Gemini servers MAY configure their server to return "52 Gone" for requests
to "/facicon.txt" if they do not want to participate in such nonsense (thank
God I was able to convince Solderpunk to add this reponse code back in the
day).  Clients that receive a "52 Gone" for such a request SHOULD NOT make
another request for it.  But those who run Gemini servers SHOULD NOT expect
to see no further requests from a given IP address---there might be several
people sharing an IP, or one user might be using multiple clients.  The
whole intent of serving up a "52 Gone" is to add said server to a list of
servers 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.  This
can 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 his
favicon.txt specification to let others know of the options available.

  Second, alt-text for preformatted blocks.  The original spec did not allow
any text past the "```".  It was later changed for reasons of accessibility,
but intentionally left ambiguous for a consensus to form around it.  I think
disallowing text on the closing "```" is too excessive and I will most
likely rescind that decision to allow more options.  But as for specifying
an actual format in the specification?  No.  Best practice, yes, but a solid
convention needs to arise first.

  Third, meta data for text/gemini.  Again, like alt-text for preformatted
blocks, this isn't something for the specification.  Again, it would be best
for the community to define a convention first.  My own opinion here is that
meta data is always nice (Lord knows I have enough in my blog [2]) but
having been through the "Sematic Web" era, not enough content creators care
enough to actually do the work.

  Fourth, I would like to state that newcomers to the mailing list might not
be aware of the history and context that Gemini was developed in, and think
of Gemini as a "stripped down web" instead of the "souped up gopher" that it
is.  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 do
it" 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 say
anything 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/


More information about the Gemini mailing list