Three month spec freeze

solderpunk solderpunk at SDF.ORG
Sun Mar 1 17:06:59 GMT 2020

Greetings all,

After today's change to the spec to introduce some new line types, I am
announcing a three month spec freeze.  I am happy to make small changes
to correct typos, fixing inconsistencies or reduce ambiguities (and I
have no doubt the latest change intorduced some of these things).  But I
will not make any substantive changes until June 1st 2020.  The reason
for this, as previously stated, is that I think in general we are doing
far too much "designing in a vacuum".

Designing protocols in the abstract on a mailing list is fun, but there
will *always* be reasonable arguments for adding just one more thing.
We'll never be finished and we'll move ever further away from the ethos
that people should be realistically able to write their own
feature-complete Gemini software in a weekend or two.  I am strongly of
the opinion that, now that we have defined something which is
(hopefully!) manageably small and simple, we should build the best
possible space we can within the limits that small and simple thing
imposes, and then ask ourselves "are we content with this?".  Not
"wouldn't it be nicer if we also had X?", because of course it would,
but "if this really were it, forever, would using this be genuinely

At this point I would really like to consider making changes if and
only if they fix actual real-world problems which we can point at that
are affecting multiple non-hypothetical servers or users.  Right now
there's just not enough stuff out there for this kind of "real world
driven design" to happen, and until that changes I think our time is
better used writing content than specs or code.

Moving forward, I strongly advocate for a model something like:

1. INTERVAL = 3 months
2. Spend INTERVAL actually building Geminispace and associated tools,
   with no major spec changes.
3. Ask "What is the *single* biggest problem/shortcoming of the current
   spec, based on everything that has actually been done or been tried
   in the past INTERVAL?"
4. Possibly (but not necessarily) change the spec to address the
   answer to 3, if the problem is deemed bad enough and can be
   addressed without adding too much extra complexity.
6. GOTO 2, or END.

This way the protocol solidifies pretty rapidly, and all our attention
is focussed on demonstrable problems, which are tackled in order of
severity.  This model strongly encourages solving most problems not
through changes to the spec, which are precious rareties, but through
extra layers of optional convention, e.g. defining well-known endpoints
like robots.txt or sitemap.xml.  This, in turn, minimises breakage of
existing tooling.

So, let's spend most of our Gemini energy until June on creating
content and tools!  In addition to finally starting some gemlogs, I
still plan to prioritise the creation of an Atom-based aggregator to
play the role of Bongusta for Geminispace.  This, I hope, will encourage
content creation by making new content easily discoverable.  In
Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog
listing played a strong role in easy content discovery.  Geminispace is
still stuck with manually checking every known server every day to find
infrequent updates, which is not something many people are going to want
to do (even I quickly stopped doing it!).  This discourages writing
content, due to the feeling that it will never be seen.  Fixing this is,
I think, important.


More information about the Gemini mailing list