Jason McBrayer jmcbray at carcosa.net
Mon Feb 22 16:33:36 GMT 2021
- - - - - - - - - - - - - - - - - - -
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) werecorrect in substance, but wrong in form. It would have been much betterto raise the issue on the mailing list, with your arguments against thefavicon 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 ina 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 atthis point the favicons convention experiment should be abandoned byclients. Two things: first, the favicons convention is wrong, but it'snot *obviously* wrong, because it doesn't affect the protocol, thegemtext format, or otherwise cause any backward compatibility issues.Secondly, when Mozz introduced the favicon convention, Gemini was in amuch greater state of flux, and the community more experimental than itis 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 thatthey did nothing wrong in that context, and proceeded exactly as theyshould have.
With hindsight, the "one resource, one request" principle looks moreimportant with regard to privacy than it did at that time, and that'swhy I'd recommend dropping support for favicons. But implementingfavicons 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 themailing list is suffering in his relative absence; a limitation of theBDFN (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 thesituation.
-- 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