Project Gemini is my effort to design a new application-level internet
protocol for the distribution of arbitrary files, with some special
consideration for serving a lightweight hypertext format which
facilitates linking between files.
Gemini is not an exercise in absolute, brutal minimalism, and will not
result in a "featherweight" protocol. This doesn't mean featherweight
protocols are bad, I think they're interesting and fun, it's just not
what this project is about. Informally, Gemini is about designing a
protocol which maximises "power to weight ratio" without crossing the
line from "lightweight" to "mediumweight" (I don't know what this
means, but I trust that I'll know it when I see it). Even less
formally, and in the grand internet tradition of meaningless car
analogies, Gemini is a protocol answer to the question "What is the
closest thing you can build to a HUMVEE which still weighs less than a
Volkswagen Beetle and can be maintained by a backyard mechanic?".
Gemini looks to gopher (mostly great, but with some undeniable pain
points) and to the web (mostly bad, but with some good ideas and
valuable capabilities) for examples of potential problems associated
with protocols which are close to the lower and upper extremes of
complexity/capability, and strives to walk a middle path between them.
It is inspired by both, but is not backward-, upward- or
sideways-compatible with either. Gemini is not intended to replace
either gopher or the web, but to co-exist peacefully alongside them.
In the same way that many people serve the same content via gopher and
the web, people will be able to "bihost" or "trihost" content on
whichever protocols they think offer the best match to their technical,
philosophical and aesthetic requirements and those of their intended
audience.
Design criteria
---------------
Simplicity:
* It should be possible for somebody who had no part in designing the
protocol to accurately hold the entire protocol spec in their head
after reading a well-written description of it once or twice.
* A basic but usable (not ultra-spartan) client should fit comfortably
within 50 or so lines of code in a modern high-level language.
Certainly not more than 100.
* A client comfortable for daily use which implements every single
protocol feature should be a feasible weekend programming project
for a single developer.
Privacy:
* The privacy disaster of the modern web must be avoided at all costs.
Nothing which could conceivably be used as an equivalent of cookies,
Referer or User-Agent headers will be included. The cautionary
tales of browser fingerprinting and Etag-based "supercookies" should
be kept in mind: it's not enough to avoid designing in features
which obviously facilitate tracking. The protocol design should
assume active, malicious efforts to sneak tracking in, and minimise
the potential for this as much as possible - even if this means
missing out on nice features with legitimate uses.
* It's not the 90s anymore, and sadly it never will be again. In some
countries it's perfectly legal for ISPs to log anything that they
receive from or send to their customers, analyse those logs, and
sell the results to marketers. In other countries, so-called "deep
packet inspection" is used to terminate connections when certain
forbidden words or phrases are recognised. The protocol must not
stick its head in the sand with regard to this.
Functionality:
* The "first class" application of Gemini is human consumption of
predominantly written material - to facilitate something like
gopherspace, or like reasonably-used webspace (something which is
comfortably usable in lynx etc.) Where possible, the protocol
should be designed to minimise the overhead associated with this
application.
* But, just like HTTP can be, and is, used for much, much more than
serving HTML, Gemini should be able to be used for as many other
purposes as possible without compromising the simplicity and
privacy criteria above. Simplicity and privacy always come first,
and text for humans always comes first, but if it's possible to do
something else simply and privately, Gemini should support it,
even if it's obviously not the best tool for the job. This means
taking into account possible applications built around non-text
files and non-human clients. A robust, general purpose tool for
sending arbitrary information across networks is darn handy, and
there is no reason that such a thing needs to be particularly
complex.
Do you really expect anybody to use this?
-----------------------------------------
I am under no delusions that Gemini will be "the next web" or anything
like that. I certainly don't expect Gemini to become widely known or
widely used any time soon. That's okay. The vibrant and wonderful
gopher community is undeniable evidence that a very small group of
enthusiasts united around an interesting protocol is more than enough
to facilitate...well, a vibrant and wonderful community. If Gemini
ends up supporting 25% as many regularly updated personal sites as
there are regularly updated personal gopherholes, then I will be very
happy and consider the project a success.
I plan to encourage early adoption by building (or encouraging other
people to build) tools like:
* A Gemini-to-gopher proxy so that Gemini clients will immediately be
able to be used to read all existing gopher content alongside the
very small amount of new Gemini content that will exist in early
days.
* A Gemini server which knows how to parse the gophermap or equivalent
formats of some of the most popular gopher servers, so that people
can immediately start bihosting their content on gopher and Gemini
with very little effort by just pointing the Gemini server at
exactly the same /var/gopher or whatever directory they already
have.
What's with the name?
---------------------
Why "Gemini"? It's a reference to the pre-shuttle era of US manned
spaceflight, which consisted of three projects. The first was Project
Mercury, which was a fairly minimalist "proof of concept" and part
of the race to put a human in space soonest. Mercury was a one-man
capsule with no ability to adjust to its own orbit after launch and
only one flight lasted longer than a day. The last was Project
Apollo, which was large, heavy, complicated and expensive but could,
of course, fly three men to the moon and back. Less well known to the
modern public, Project Gemini was the "middle child": a two person
capsule which could rendezvous and dock with other craft in orbit,
could be depressurised and repressurised in orbit to facilitate
spacewalks, and whose longest flight was almost two weeks - longer
than any Apollo mission! In terms of size, weight and cost Gemini was
much closer to Mercury than to Apollo, but in terms of capabilities it
was the other way around - there were even plans (which never
eventuated) to do circumlunar Gemini flights!
I hope the analogy is obvious: Mercury = gopher and Apollo = the web.
I very deliberately didn't choose a name which had *anything* to do
with gopher, or other rodents, or even other animals. Some people in
the phlogosphere seem to think that the discussions of new protocols
represent a threat to gopher, and/or that those taking part in the
discussions want to replace gopher with something new, or worse want
to build these new ideas into gopher clients and servers as
unofficial, compatibility-breaking upgrades. This is partially our
own fault for not talking more carefully in the earliest days of this
discussion. But none of those things are true for me, and I really
think they are a minority opinion, if indeed not an outright strawman.
To minimise the risk of further confusion, I chose a totally
non-gophery name and will only ever refer to Gemini as
"gopher-inspired" (and to be clear, it's definitely web-inspired,
too!), not "based on gopher" or "an upgrade to gopher" or anything
else like that.
