[Spec] Spec (un)freezes and the spec's future

[Solderpunk]

On Sun Dec 20, 2020 at 7:52 AM CET, Alex // nytpu wrote:

> Solderpunk at some point mentioned a temporary spec freeze, unfreezing
> for early 2021, then permanently finalizing the spec. I have no idea if
> this is still the plan or not, but I still feel it would be a good idea
> to discuss: what modifications would be made to the spec in an
> "unfrozen" period, if any; what modifications would be made to the spec
> in its permanent finalization stage; and how companion specs and the
> like would be dealt with, both now and in the finalization stage.

To be honest, I don't at this point remember precisely what I said
previously, but my hope is still to have this whole thing finalised in
the first half of 2021, and even better in the first quarter.  I'm not
sure there's much value at this point to establishing an exact schedule
with clearly demarcated frozen/unfrozen states.  The permanent freeze on
non-trivial new features I announced several months ago is, well, still
in place because that's what permanent means.  There are a few issues
under consideration right now (the IRI/IDN issue, a desire for clarity
on "streaming" responses, and some finicky point about URLs which I need
to remind myself of), and I'm preparing to start finally addressing
these things during my time off between Christmas and the New Year
(expect me to finally offer some thoughts on the IRI/IDN thing in the
new few days).  I don't envision anything else being given serious
consideration.

> Onto a permanent spec freeze, if such a thing would occur. I believe
> making the spec totally immutable would be arrogant on our part, because
> you can't pretend that it is 100% perfect.

Things don't need to be 100% perfect to be useful.  I think it's
arrogant to *aim* for perfection.  I know it's very much going against
the grain to declare than any kind of software project is "done"; I know
that people nowadays explicitly avoid using or recommending software for
the sole reason that it is no longer being actively developed.  I
honestly think this is all very strange and backwards.  If, after an
initial busy development period of a year or so, each new release of a
program does not come out after a longer delay than the last one, it
probably means either the program is poorly designed and each fix or
improvement introduces more problems than it solves, so it's doomed to be
unreliable and/or inefficient forever, or else the program's scope is
too wide or too poorly defined, in which case it is doomed to expand
forever, growing ever more complex and featureful until it inevitably
becomes poorly designed and faces the same fate above.  There's no reason
that network protocols with humble aspirations should be any different.
Things can be "finished" and remain useful as-is for decades.  Perhaps
not forever, but certainly for decades.

Gopher is a great example here.  RFC 1436 is coming up on 28 years old
now.  There are very few changes/extensions to that specification which
are so widely used in Gopherspace today as to be considered basically
mandatory.  All those changes are themselves at least 20 years old at
this point, and they're minor enough that if the RFC were updated to
include them, it would likely not grow in length by more than 10%, and
90% of the lines would remain unchanged.  Despite this fossilised
status, Gopher remains useful, in use and well-loved today, and is in
fact undergoing a small resurgence.  It's proof that if you keep things
simple enough, you can get close enough to "right" the first time, which
is very much what I'd like Gemini to achieve.  It's true Gemini is more
complicated than Gopher - but it's also, I imagine, been designed by a
larger group of people over a longer period of time than Gopher was, and
at this point has received non-trivial real-world testing.

All of which is to say that I really do want to attempt a permanent spec
freeze.  I suppose I reserve the right to change my mind if cold hard
reality proves me wrong, but for now I don't really want to bother
making plans for how to handle this.

> Finally, I'd like to address companion specs. Especially if the spec is
> permanently finalized, there will be companion specs popping up all over
> the place. This can be viewed as good, because it means that each spec
> is nice and unix-y, doing only one thing each. This creates the problem
> the web has though, where authors are expected to support an amorphous
> and constantly changing group of specs and results in huge applications
> that are impossible to maintain. Even if companion specs like Titan are
> fine now, it leaves a huge opening for the web-ification of gemini in
> the future WHEN (not if) FAANG-inspired malicious actors take an
> interest in it. There are a few ways to address this, from the hardliner
> approach of completely disallowing companions to the 100% inclusive
> approach of creating a dedicated RFC listing. Obviously a middle ground
> will have to be found, but a discussion on where exactly that may be is
> warranted. You don't want to cut out useful things like titan, but you
> also don't want to leave a huge extensibility window open.

I don't see how completely disallowing companion specs is really
possible.  I could refuse to host them or to bless them as "official",
but if they're popular enough, people will implement them anyway.  Our
strongest possible defense here, IMHO, is keeping the core protocol so
easy to implement that there is always likely to be a wide variety of
clients in popular use.  That way, companion protocols cannot gain
traction unless multiple independent client developers all agree they
are worth supporting.  Anything contentious is doomed to never achieve
more than minority support.  The wider the variety of clients in use,
the harder it is for individual actors to push divisive expansions.

This is really a two-part defense strategy.  There's a technical part,
addressed through the spec itself, which is to make sure that client
implementation remains as easy as possible, but also a cultural part.
The cultural part is to cherish diversity and encourage a DIY ethic.

Cheers,
Solderpunk