Status20 Success
Metatext/plain; charset=utf-8
# Project Gemini FAQ

## 1. Overview

### 1.1 What is Gemini?

Gemini is 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 intended to be simple, but not necessarily as simple as
possible.  Instead, the design strives to maximise its "power to
weight ratio", while keeping its weight within "acceptable" limits.
Gemini is also intended to be very privacy conscious.

You may think of Gemini as "the web, stripped right back to its
essence" or as "Gopher, souped up and modernised a little", depending
upon your perspective.

### 1.2 Whose fault is Gemini?

Project Gemini was started by Solderpunk <solderpunk@sdf.org>, who
remains Benevolent Dictator For Now.  However, the protocol has been
designed in collaboration with a loose and informal community of
interested parties via emails, phlog and Fediverse posts.  Many people
have shaped significant parts of the protocol, so Gemini should not be
thought of as the work of one person.

### 1.3 Where can I learn more?

The official home of Project Gemini is the gemini.circumlunar.space
server.  It serves the latest version of this FAQ document, as well
the protocol specification and recommended best practices via Gemini,
Gopher and HTTPS, on IPv4 and IPv6.

Official discussion regarding Gemini hapens on a mailing list.  You
can subscribe to the list and view archives at
gemini://lists.orbitalfox.eu/listinfo/gemini.  Anybody who is running
a Gemini server or implementing a Gemini client or server software is
strongly encouraged to subscribe to the list.

### 1.4 Do you really think you can replace the web?

Not for a minute!  Nor does anybody involved with Gemini want to
destroy Gopherspace.  Gemini is not intended to replace either Gopher
or the web, but to co-exist peacefully alongside them as one more
option which people can freely choose to use if it suits them.  In
the same way that many people currently serve the same content via
gopher and the web, people will be able to "bihost" or "trihost"
content on whichever combination of protocols they think offer the
best match to their technical, philosophical and aesthetic
requirements and those of their intended audience.

### 1.5 What's with the name?

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 (which the Soviet Union won with their
Vostok project).  Mercury was a one-man capsule with no ability to
adjust to its own orbit after launch and only one Mercury flight
lasted longer than a single 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!

Hopefully the analogy is obvious: Gopher is akin to Mercury, and the
web is akin to Apollo.  Gemini hopes to sit between the two, doing
more with less.

Gemini very deliberately didn't receive a name which had *anything*
to do with gophers, or other rodents, or even other animals.  During
the earliest phlog-based discussions which eventually grew into
Project Gemini, a lack of careful writing meant it was sometimes
unclear whether people were talking about replacing Gopher outright,
or adding unofficial, compatibility-breaking upgrades into existing
Gopher clients and servers.  When idle discussion turned into an
actual project, it seemed wise to send a clearer message.

# 2. Protocol design

## 2.1 What are the design criteria for Gemini?

The following criteria were informally put in place at the beginning
of the project.  It's debatable how closely some of these goals have
been met, but in general Gemini is still quite close to this target.

### 2.1.1 Simplicity

In particular, Gemini strives for simplicity of client implementation.
Modern web browsers are so complicated that they can only be developed
by very large and expensive projects.  This naturally leads to a very
small number of near-monopoly browsers, which stiffles innovation and
diversity and allows the developers of these browsers to dictate the
direction in which the web evolves.

Gemini aims to be simple, but not *too* simple.  Gopher is simpler at
a protocol level, but as a consequence the client is eternally
uncertain: what character encoding is this text in?  Is this text the
intended content or an error message from the server?  What kind of
file is this binary data?  Because of this, a robust Gopher client is
made *less* simple by needing to infer or guess missing information.

Early Gemini discussion included three clear goals with regard to
simplicity:

1. 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.
2. 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.
3. A client comfortable for daily use which implements every single
   protocol feature should be a feasible weekend programming project
   for a single developer.

It's debatable to what extent these goals have been met.  Experiments
suggest that a very basic interactive client takes more like a minimum
of 100 lines of code, and a comfortable fit and moderate feature
completeness need more like 200 lines.  But Gemini still seems to be
in the ballpark of these goals.

### 2.1.2 Privacy

Gemini is designed with an acute awareness that the modern web is a
privacy disaster, and that the internet is not a safe place for
plaintext.  Things like browser fingerprinting and Etag-based
"supercookies" are an important cautionary tale: user tracking can and
will be snuck in via the backdoor using protocol features which were
not designed to facilitate it.  Thus, protocol designers must not only
avoid designing in tracking features (which is easy), but also assume
active malicious intent and avoid designing anything which could be
subverted to provide effective tracking.  This concern manifests as a
deliberate non-extensibility in many parts of the Gemini protocol.

### 2.1.3 Generality

The "first class" application of Gemini is human consumption of
predominantly written material - to facilitate something like
gopherspace, or like "reasonable webspace" (e.g. something which is
comfortably usable in Lynx or Dillo).  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.  This means
taking into account possible applications built around non-text
files and non-human clients.

## 2.2 Which shortcomings of Gopher does Gemini overcome?

Gemini allows for:

* Unambiguous use of arbitrary non-ASCII character sets.
* Identifying binary content using MIME types instead of a small set
  of badly outdated item types.
* Clearly distinguishing successful transactions from failed ones.
* Linking to non-gopher resources via URLs, without ugly hacks.
* Redirects to prevent broken links when content moves or is
  rearranged.
* Domain-based virtual hosting.

Gemini does away with Gopher's strict directory / text dichotomy and
lets you insert links in prose.

Gemini mandates the use of TLS encryption.

## 2.3 Which shortcomings of the web does Gemini overcome?

Gemini contains no equivalent of User-Agent or Referer headers, and
the request format is not extensible so that these cannot be
shoehorned in later.

The "native content type" of Gemini (analogous to HTML for HTTP(S) or
plain text for Gopher) never requires additional network transactions
(there are no in-line images, external stylesheets, fonts or scripts,
no iframes, etc.).  This allows for quick browsing even on slow
connections and for full awareness of and control over which hosts
connections are made to.

The native content type of Gemini is strictly a document, with no
facility for scripting.

## 2.4 Is Gopher's directory / text dichotomy really a shortcoming?

Modern usage habits in the phlogosphere would seem to suggest that
many people think it is.  An increasing number of users are serving
content which is almost entirely text as item type 1, so that they can
insert a relatively small number of "in line" links to other gopher
content, providing some semblence of HTML's hyperlinking - a perfectly
reasonable and inoffensive thing to want to do.  Without taking this
approach, the best Gopher content authors can do is to paste a list of
URLs at the bottom of their document, for their readers to manually
copy and paste into their client.  This is not exactly a pleasant user
experience.  But forcing hyperlinks into Gopher this way isn't just an
abuse of the semantics of the Gopher protocol, it's also a
surprisingly inefficient way to serve text, because every single line
has to have an item type of i and a phony selector, hostname and path
transmitted along with it to make a valid Gopher menu.  Any and all
claims to simplicity and beauty which Gopher might have are destroyed
by this.  Gemini takes the simple approach of letting people insert as
many or as few links as they like into their text content, with
extremely low overhead, but retains the one-link-per-line limitation
of Gopher which results in clean, list-like organisation of content.
It's hard to see this as anything other than an improvement.

Of course, if you really like the Gopher way, nothing in Gemini stops
you from duplicating it.  You can serve item type 0 content with a
MIME type of text/plain, and you can write text/gemini documents where
every single line is a link line, replicating the look and feel of a
RFC1436-fearing Gopher menu without that pesky non-standard i item
type.

## 2.5 How can you say Gemini is simple if it uses TLS?

Some people are upset that the TLS requirement means they need to use
a TLS library to write Gemini code, whereas e.g. Gopher allows them
full control by writing everthing from scratch themselves.

Of course, even a "from scratch" Gopher client actually depends
crucially on thousands of lines of complicated code written by other
people in order to provide a functioning IP stack, DNS resolver and
filesystem.  Using a TLS library to provide a trustworthy
implementation of cryptography is little different.

## 2.6 Why don't you care about retrocomputing support?

Gopher is so simple that computers from the 80s or 90s can easily
implement the protocol, and for some people this is one of the great
virtues of Gopher.  The TLS requirement of Gemini limits it to more
modern machines.

Old machines are awesome, and keeping them running, online and useful
for as long as possible is an awesome thing to do.  But it also makes
no sense for the vast majority of internet users to sacrifice any and
all privacy protection to facilitate this.  Remember, though, that
Gemini does not aim to replace Gopher, so the retro-compatible
internet is not directly endangered by it.  In fact, people serving
content via Gopher right now are strongly encouraged to start also
serving that same content via Gemini simultaneously.  Retrocomputing
fans can continue to access the content via Gopher, while modern
computer users who wish to can switch to Gemini and reap some beneits.