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