-- Leo's gemini proxy

-- Connecting to git.thebackupbox.net:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

repo: gemini-site
action: commit
revision:
path_from:
revision_from: fce8f1ee8bb4d9394e5f23e48d16adf466dbfbe9:
path_to:
revision_to:

commit fce8f1ee8bb4d9394e5f23e48d16adf466dbfbe9
Author: Solderpunk <solderpunk@posteo.net>
Date:   Sun Nov 1 14:35:09 2020 +0100

    Spell check and minor stylistic change to FAQ.

diff --git a/docs/faq.gmi b/docs/faq.gmi

--- a/docs/faq.gmi
+++ b/docs/faq.gmi
@@ -51,7 +51,7 @@ The following criteria were informally put in place at the beginning of the proj

 ### 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.
+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 stifles 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:

@@ -88,7 +88,7 @@ Gemini mandates the use of TLS encryption.

 ## 2.3 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 port 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.
+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 semblance 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 port 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.

@@ -106,7 +106,7 @@ Many people are confused as to why it's worth creating a new protocol to address

 Of course, this is possible.  "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience.  We know it can be done.

-The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way.  It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it.  It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user.  It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences.  Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch.  Even if you did it, you'd have a very difficult time discovering the minuscle fraction of websites it could render.
+The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way.  It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it.  It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user.  It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences.  Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch.  Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.

 Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions.  You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it.  While you're there, you know for sure and in advance that everybody else there is playing by the same rules.  You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they *can't*.  You can do all this with a client you wrote yourself, so you *know* you can trust it.  It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.

@@ -118,7 +118,7 @@ Gemini has no support for caching, compression, or resumption of interrupted dow

 ## 2.7 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.
+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 everything 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.

@@ -138,7 +138,7 @@ TLS is certainly not without its shortcomings, but:
 The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini?  Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages".  Reasons not to go down this route include:

 * There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly.
-* The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a simple Gemini client is a needless intermediary format which is heavier than the original!
+* The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original!
 * Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images.
 * A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs.

@@ -152,7 +152,7 @@ It's true that you need to shift your thinking a bit to get used to the one link

 ## 2.11 Why isn't there an equivalent of the HTTP Content-length header?

-Non-extensibility of the protocol was a major design principle for Gemini.  Things like cookies, Etags and other tracking tools were not present in the origial design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers.  To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to included one and exactly one piece of information in the response header for successful requests.  Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again.  There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality.  Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length.  The same is true for other harmless and useful HTTP headers, like Last-Modified
+Non-extensibility of the protocol was a major design principle for Gemini.  Things like cookies, Etags and other tracking tools were not present in the original design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers.  To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to included one and exactly one piece of information in the response header for successful requests.  Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again.  There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality.  Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length.  The same is true for other harmless and useful HTTP headers, like Last-Modified

 Gopher also has no equivalent of the Content-length header, and this has not proven to be a practical obstacle in Gopherspace.

@@ -170,7 +170,7 @@ This may seem radical or unwise, but we're cautiously optimistic.  The Gopher sp

 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.
+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 benefits.

 # 3. Getting started in Geminispace

@@ -185,7 +185,7 @@ If you like what you see, you might want to consider installing a dedicated Gemi

 You can try some terminal clients out without installing them by running:

-ssh kiosk@gemini.circumlunar.space
+> ssh kiosk@gemini.circumlunar.space

 This Gemini kiosk was inspired by the Gopher kiosk at bitreich.org!

-- Response ended

-- Page fetched on Sun Jun 2 17:35:13 2024