Sean Conner sean at conman.org
Tue Feb 23 00:16:26 GMT 2021
- - - - - - - - - - - - - - - - - - -
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, nota 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 andserver.
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 wasfirst written. I've mentioned in other messages the differences from thenand now. But saying it has only ever had "minor clarifications" is historyrevisionism.
-spc