[tech] [spec] On extending gemini

[Sean Conner]

It was thus said that the Great Drew DeVault once stated:
> This
> historical revisionism about how Gemini is a platform for Gophers to
> feed their creativity into expanding upon Gopher's limitations is
> ridiculous.  

  Michael is correct---you are not.  Gemini *is* an expansion of gopher, not
a reimagining of the web.  Citing primary sources here (Solderpunk himself):

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/pondering-whats-inbetween-gopher-and-the-web.txt

	It's no secret, of course, that I love gopher.  Some of my reasons
	are outlined in previous writings[2].  And it's neither a secret
	that I hate the web, or at least it's modern incarnation.  Both of
	these things can be, and are, true while I still believe that Gopher
	is not perfect and has shortcomings, and there are things about the
	web experience to miss when one surfs on port 70.  So lately I've
	been thinking about "the space inbetween", about hypothetical dream
	protocols which are more than gopher but less than HTTP.

	...

	As a first contribution to this line of thinking, I have come up
	with a protocol which basically consists of three small changes to
	gopher which address what I *think* I currently believe are its
	three greatest shortcomings.

	The first change is that TLS encryption of all connections is
	mandatory.  No two port cleartext/cyphertext distinction like HTTP
	and HTTPS, no upgrade from cleartext using STARTTLS, just secure
	connections from the get go and that's it. ...

	The second change is that the standard non-directory item type is
	not a plaintext file, but a text file in some very lightweight,
	human-readable markup language which supports inline linking to
	other resources.  ...

	The third and final change is the introduction of an item-type which
	means "interpret this selector and interact with it in some way
	determined by its schema".  The 'h' item-type already plays this
	role for many more advanced clients, if you put a "URL:" in front of
	the selector, but this is IMHO an ugly hack which really spoils the
	clean semantics of the gopher protocol.  And item-type of 'h' is
	supposed to and *should* mean "this is a HTML file", and item-types
	shouldn't do double duty as it defeats the point of them.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt

	I'm talking about the fact that my hypothetical new protocol
	operated strictly over TLS connections - plaintext straight up
	wasn't an option.  I am of the opinion that the widespread lack of
	encryption in gopherspace today is the protocol's biggest
	shortcoming, and I actually suspect that this point alone
	discourages some folks who would otherwise be on board from adopting
	it.  But others, including Bongusta overlord Logout, do not see the
	need, so here's my attempt at a justification.

	...

	The web is surely a dumpster fire, but let's not pretend gopher is
	perfect and cannot be improved.  Those of us fleeing the web have
	just fallen back here because it's about the only off-the-shelf
	vaguely web-like thing that there is to fall back to.  Some of us
	may be truly comfy here, and that's absolutely fine.  Increasingly I
	think I'd like to use gopher as a temporary base of operations to
	build something even better.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/more-on-gopher-and-crypto.txt

	My recent post[1] about "why gopher needs crypto" received a very
	well-considered response[2] over at The Boston Diaries.  The author
	(do I call you "the conman"?) rightly points out that the true
	challenge is not in actually conducting a gopher request/response
	transaction over a TLS connection, which in relatively trivial and
	has been done before.  Rather, the core difficulty lies in the
	absence of any way to represent in a type-1 response that a
	particular gopher resource is accessible via TLS.

	...

	The conman suggests that creating a new protocol is to risk that we
	"start falling into HTTP territory".  This is of course a very real
	risk, but I also very strongly believe that it is perfectly
	avoidable if we are sufficiently determined from day one to avoid
	it.  To this end, I hope to think and write (and read, if anybody
	wants to join in!) more in the future not just about the
	shortcomings of gopher but very explicitly about what is right and
	what is wrong about HTTP and HTML.  It's vitally important to
	identify precisely what features of the web stack facilitated the
	current state of affairs if we want to avoid the same thing
	happening again.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/the-soul-of-gopher.txt

	What is the "true spirit of gopher"?  Its "heart and soul", the
	deep, conceptual commitment which distinguishes it from other
	protocols, in particular from the web?

	...

	Now that we've uncovered the true spirit of gopher, the natural
	question, for those participating in the on-going discussions about
	new gopher-inspired protocols, is whether or not this idea is one
	that the gopher community really cherishes and which should be
	preserved in the Ultimate New Protocol of Truth and Glory.

	...

	... There's plenty of evidence out there that a lot of Gopher
	enthusiasts don't actually *want* a protocol that divides sharply
	between navigation and content.  They just want to be able to serve
	plain-text with hyperlinks anywhere they like, via a bare bones
	protocol that doesn't support tracking and other unpleasantries. 
	Something like "HTML with only the <a href> tag, over HTTP/0.1".  I
	think that's all *I* want.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/protocol-pondering-intensifies-ii.txt

	In the previous post in this series[1] I compared request formats
	for gopher and HTTP and thought a bit about what a good anonymous
	document system actually needs.  I ended up deciding that the answer
	was nothing more than gopher already provides.  In this post I'll
	continue that discussion, focussing instead on the response format.

	...

	This protocol is not as simple as gopher, but I would argue its
	power to weight ratio is substantially greater.  ...

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/protocol-pondering-intensifies-iii.txt


	A standard gopher menu line looks like this:

	...

	An obvious update which could be made here is to take advantage of
	the fact that between now and gopher was first invented, URLs have
	been invented!  We don't need to specify the selector (path), host
	and port separately, we have a standard way to build that into one
	string, and every modern programming language has libraries for
	parsing/buiding them. ...

gopher://zaibatsu.circumlunar.space/0/~solderpunk/gemini/cold-blanketry.txt

	The Gemini project has attracted more attention in a short time
	frame than I expected, and on the whole the project is moving very
	fast!  It's quickly becoming apparent that not everybody is going to
	agree with everybody else about what the best path forward for the
	project is.  If things keep moving this fast, it's going to be very
	hard to keep building and maintaining consensus among the entire
	community.

	I understand that this seems kind of sad and kind of scary, but I
	think (and surely hope!) that it will be okay.

	The worst case scenario as I see it is that the Gemini project
	quickly descends into internal arguments, nobody can agree on
	anything and the whole thing fizzles out in a week.  If that
	happens, we've all still got gopher, which isn't going anywhere. ...

  If you have a rebuttle, fine, but "citation needed."

> The purpose of Gemini has always been crystal clear. 

  Yes, a new gopher.  Ahd simplicity of implementation for both client and
server.

> The
> spec has received only minor clarifications and has always come with the
> following promises:

  No.  The spec has received *major* changes and clarifications since it was
first written.  I've mentioned in other messages the differences from then
and now.  But saying it has only ever had "minor clarifications" is history
revisionism.

  -spc