| # What is gopher?
      |
      | This file serves to attempt to disprove common misconceptions about gopher, here
      | goes.
      |
      | {1} Gopher is: a filetype-agnostic transfer protocol.
      |        
      |         For a client to request a file, it sends a string like so:
      |
      |         path<CR><LF>
      |
      |         To  the server  -  <CR> is  a  shorthand for a carriage return, and <LF>
      |         is  a  linefeed,   aka  newline.   The  "path"  could  theoretically  be
      |         anything,  however almost  all gopher servers  expect a  unix-like path.
      |         For example:
      |
      |         /docs/gopher.txt
      |
      |         The  server then  starts  sending the *unmodified* contents of the file.
      |         *unmodified*  does not  mean the  server  can't  modify  the file  -  it
      |         means  the client  is not  expected to  un-modify  a file when recieved,
      |         so if  the server modifies  the  contents to, for example,  compress the
      |         file,  the client  will not have  any way to expect that and will choke.
      |
      |         When the server is finished sending the file, it sends the following:
      |
      |         .<CR><LF>
      |
      |         This is so that the client knows it has recieved the full file, with no
      |         truncation.
      |
      | {2} Gopher is not: plaintext only
      |         see the above paragraph
      |
      | {3} Gopher is also: a menuing system
      |
      |         A menu is a set of "links" or "pseudo-links".
      |         Menus use the following form:
      |
      |                 <t><desc>\t<path>\t<hostname>\t<port>
      |        
      |         <t>        == A "type".  Types specify to the client what to expect when
      |                       following a link,   for example '1' means a "directory" or
      |                       gopher  menu.   Types   must   be  one   character   long.
      |         <desc>     == A   description  of   the link,  can contain any character
      |                       except an ascii tab.
      |         <path>     == The same  "path"  as described in the first paragraph, can
      |                       contain any char except a tab.
      |         <hostname> == The hostname of a server, can be dns based, a direct ipv4,
      |                       ipv6, etc. This is only limited by the capabilities of the
      |                       client.
      |         <port>     == The port of a server.
      |         \t         == An ascii tab character.
      |
      |         To link to a resource on the same server, the <hostname> and <port> must
      |         be the server itself - many gopher servers provide a way to fill in this
      |         info for you.  For example the gophernicus server allows you to omit the
      |         <hostname>  and  <port>,  appending  internally defined  values instead.
      |
      |         The  geomyidae server takes a  wildly different approach. geomyidae uses
      |         it's  own gophermenu  syntax,  to see more details, look at the man page
      |         [1].  To link internally, type the literal words "server" or "port" in a
      |         link.  For example,  if running  on  haydenvh.com  with  port 70,  this:
      |
      |                 [1|internal resource|/file.txt|server|port]
      |        
      |         Will be translated to:
      |
      |                 1internal resource        file.txt        haydenvh.com        70
      |
      |         (note, instead of using actual tabs I use spaces for the examples).
      |
 Text |         Follow this link to see the "gph" source of this page
 Text |         Here is a list that shows canonical and common types.
      |
 Text |         [1]
      |
      | {4} Gopher is not: purely static
      |
      |         This  is a  very flawed  misconception.  The gopher protocol does not in
      |         *any*  way prevent  dynamic  content. In  fact,  the majority of servers
      |         support  dynamic  content  generation  by  default,  and do this simpler
      |         compared to most web servers.
      |
      |         Dynamic generation varies from server to server, as there is no standard
      |         for  this - at first this seems like a negative, but it ultimately means
      |         more  freedom for the person creating the  content, as they can choose a
      |         server that is right for them.
      |
      |         Many  servers generate  dynamic directory listings  -  this is likely to
      |         happen  even if  you don't  create  any  explicit "dynamic files/menus".
      |
      |         Gopher  also supports  a way  to input text to a server. This is done by
      |         appending a tab, followed by the query to the "path" sent to the server.
      |
      |         Another  example of  dynamically generated content defined by the server
      |         itself is  web redirects.  The server  here sends the client a html file
      |         designed to redirect to the specified web page.
      |
      | {5} Gopher has: a uri scheme
      |
      |         gopher://<host>[:port]/<type>[path][\tquery]
      |
      |         Anything  wrapped with  angle brackets  <>  is required, anything within
      |         square brackets [] is optional. The "port" defaults to 70, if no path is
      |         given, the server sends the "root page", which most of the time contains
      |         links to submenus or content.  The "query" does not default to anything.
      |
      | {6} Gopher does not need: mimetypes
      |
      |         This is a controversial statement, and this point is mainly my opinion.
      |
      |         Mime-types are primarily designated  based off of the extension given to
      |         a file path. Therefore it seems resonable for the *client* to be able to
      |         look at this.  In fact,  it is possible for clients to completely ignore
      |         the extensions and  implement their own ways of  handling files, such as
      |         by using file(1)  to inspect the contents of a file to determine what to
      |         do with it.  This is more programmable,  as the  server doesn't tell the
      |         client what to do.
      |
      | {7} Gopher does not have: text formatting
      |
      |         See the following point.
      |
      | {8} Gopher servers do not: tell clients how to render content
      |
      |         There  is no  native text  formatting  language  like  HTML  on  gopher.
      |         Instead,  the client and/or the user  can define what is displayed. This
      |         is a similar  approach to  what email clients do with plaintext mail, or
      |         irc clients do with messages.
      |
      |         Here [2] is a  screenshot of  a fork of `cgo` [3], a screenshot [4] with
      |         `lynx`, and  a screenshot [5] of `curl`, which doesn't render content at
      |         all.
      |
      |         Many  writers of  gopher  content  use  `Markdown`  -  a text formatting
      |         langauge based  of human readable email  formatting. This makes sense as
      |         it  is  easily parsable  by humans,  but  could  allow  for  clients  to
      |         implement a "Markdown mode" in which they render it.  There is simply no
      |         end to client customizability.
      |
 Img  |         [2]
 Dir  |         [3]
 Img  |         [4]
 Img  |         [5]
      |
      |         To  circumvent this limitation,  many people  get creative,  using text,
      |         symbols  and whitespace  to lay  out their content, or even draw things.
      |
      | {9} Gopher is: simple
      |
      |         I hope you have already gotten this point,  as it is the #1 thing I want
      |         you to take away from here.
      |
      |         By  being simple  and  stupid in design, it is easy to shape gopher into
      |         forms.  A basic  gopher client  capable of  fully rendering content is a
      |         very  manageable project for  any person  who has basic understanding of
      |         programming.  This is  very much unlike  the web,  where  there are only
      |         really a few web "engines", with most browsers/clients only differing by
      |         the user  interface hastily  glued onto  the  "engine".  This  should be
      |         unnaceptable to the end user.
      |
      |         Instead  of  making  it easier  to use  the web,  the  majority  of  new
      |         technologies  convolute  it further,  and add another box to the already
      |         huge  checklist of  standardized  features,  instead  of rubbing out and
      |         redoing bad design decisions.
      |
      | {10} Gopher is also: easily convertable to HTML.
      |
      |         This is  a fun little  side note.  I made a http server [6] a while back
      |         that can convert standard gopher content, and geomyidae content to HTML.
      |         This is not the only such proxy, but it is *the* server that is designed
      |         to do so. I have not  yet seen anyone take such an approach, as of 2020,
      |         so I am probably the  inventor of this idea :)  Gopher  menus are easily
      |         awkable.
      |
      |         I  use this mainly  so I  can show web peasants  information that I have
      |         exlusively  written for  gopher, it emulates my favourite (and forked by
      |         me) client, cgo [3].
      |
 Text |         [6]
      |
      | ---
      |
      | If you are running my fork of `cgo`, use the = command here to pagerize this
      | file.
      |
      | --
      | hhvn <hayden@haydenvh.com>

   This page was generated via hhttpd (http://haydenvh.com/scripts/other/httpd.sh) from geomyidae gopher content.
   You should be using gopher directly, if possible.