A proposal to freeze the Gemini specification
Sean Conner
sean at conman.org
Tue Oct 26 09:34:03 BST 2021
It was thus said that the Great Robert khuxkm Miles once stated:
> October 25, 2021 9:48 PM, "Rohan Kumar" <seirdy at seirdy.one> wrote:
>
> > Adding features is typically misguided: it's better to *complement*
> > Gemini with other protocols suited for other purposes than to *extend*
> > it. One such protocol is the spartan:// client-to-server protocol.
> > Gemini can concentrate on supporting server-to-many-client situations
> > while Spartan can concentrate on client-to-server communication.
> >
> > (This is not necessarily an endorsement of Spartan; I do have some
> > issues with it, but that's off-topic).
>
> I feel like that's a mischaracterization of Spartan. In the past, I've
> described Spartan as "gemini - tls + uploads", because that's basically
> what it is (barring some things like the =: line type for input links, and
> the one-character status codes). It's more its own protocol that happens
> to take design cues from Gemini (Sean, if I'm completely missing the point
> here, please do tell me, but this is the impression I've gotten so far).
> Perhaps you meant Titan?
I have nothing to do with Spartan. Titan, yes---I came up with the
initial idea, and it's Alex Schroeder who implemented and expanded on the
idea. But I have looked a bit into Spartan---it was developed by Michael
Lazar, and indeed, it seems to be "gemini - tls + uploads" (and he might
have been inspired by titan, inimeg or discursi. Titan is more
"an upload protocol".
There was also inimeg: (the same as titan:) and yet another scheme
(discursi?) that I can't find right now.
-spc
More information about the Gemini
mailing list