[tech] [spec] On extending gemini

[Jason McBrayer]

Drew DeVault writes:

> I'm sorry for putting the stick on the table upfront; in hindsight it
> was rude. I always prefer friendly negotiation first.

This was my opinion of the favicons situation ? that you (Drew) were
correct in substance, but wrong in form. It would have been much better
to raise the issue on the mailing list, with your arguments against the
favicon convention up-front.

> You have every right to make statements on behalf of your software,
> too. Clients like Amfora have already done so by implementing
> favicons. Mine is a statement of opposition, and we will ultimately
> have to come to some kind of consensus. This is how protocol
> ecosystems work.

I agree, but I feel it would be better to work towards that consensus in
a more collegial manner.

> Mozz, your extensions are irresponsible. You view this medium as a
> changing, evolving platform, and accept the consequences as it is
> fleeting and ultimately doomed to ruin.

I'm going to speak in Mozz's defense here, even though I think that at
this point the favicons convention experiment should be abandoned by
clients. Two things: first, the favicons convention is wrong, but it's
not *obviously* wrong, because it doesn't affect the protocol, the
gemtext format, or otherwise cause any backward compatibility issues.
Secondly, when Mozz introduced the favicon convention, Gemini was in a
much greater state of flux, and the community more experimental than it
is today. Mozz wrote it up as a concrete proposal on the mailing list,
implemented it on portal.mozz.us, and went from there. I suggest that
they did nothing wrong in that context, and proceeded exactly as they
should have.

With hindsight, the "one resource, one request" principle looks more
important with regard to privacy than it did at that time, and that's
why I'd recommend dropping support for favicons. But implementing
favicons at that time wasn't a mistake ? it was an experiment.

> - Any changes will not require drastic changes in implementations
> - It will be frozen once time has proven it correct
>
> Solderpunk reaffirmed this on the new year.

I understand that Solderpunk is extremely busy, but I do think that the
mailing list is suffering in his relative absence; a limitation of the
BDFN (benevolent dictator for now) structure we currently have.

> Finally, to clarify the role of srht.site: I did not intend to issue
> an unstated threat of leveraging srht.site's influence to strong-arm
> Amfora in this respect. There is not a case of "deliberate timing"
> here. My statement regarding the possibility of black holeing was only
> with respect to gmnisrv, which is a minority player in the field of
> Gemini servers. I don't intend to shove this view onto all users of
> srht.site - that's well beyond the scope of appropriate influence. I
> understand why this was not clear, and I'm sorry for the confusion.

Thank you for this; this does a tremendous amount to de-escalate the
situation. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow