
Visually Mapping Gopherspace - Jaruzel
http://www.jaruzel.com/blog/Visually-Mapping-Gopherspace-in-2018
======
reaperducer
I would love to see gopher make a modest comeback. Its simplicity keeps it
from getting monetized to death. It would be great if it could once again
become the default protocol for academic and scholarly information.

I tried to run gopher on a server I once rented at Pair Networks in
Pittsburgh, and they wouldn't permit it, saying it was a security risk. Same
response when I asked about opening up the finger port.

~~~
klez
Be the change you want to see :)

For my part, I'm developing a gopher server + (minimal) app framework and plan
to use it to publish a gopher version of my blog.

~~~
classichasclass
I think this is the best way for someone who just wants to play with Gopher
initially to get started: "syndicate" whatever HTTP content you have,
appropriately distilled down to text (Markdown all the things?), to Gopher
simultaneously. And if you get action that way, maybe some exclusive Gopher
content later.

The protocol is so simple that writing your own server and client is trivial,
and it's fun.

------
bsmallbeck
Ah, Gopher. One of my favorite pieces of tech history (that refuses to be
'history,' apparently), invented at my place of work, the University of
Minnesota.

Great article on it's history:
[https://www.minnpost.com/business/2016/08/rise-and-fall-
goph...](https://www.minnpost.com/business/2016/08/rise-and-fall-gopher-
protocol)

Segment on Gopher by a local comedy show, including an interview with one of
the original devs:
[https://www.youtube.com/watch?v=LtHT_11d5t8](https://www.youtube.com/watch?v=LtHT_11d5t8)

------
mewse-hn
Any protocol for encrypted gopher?

~~~
wolfgang42
There's been some discussion about this on the gopher-project mailing list[1]
recently, but there's significant debate about the correct way to do this.
Part of the problem is that Gopher menus are fixed-format, so there's no good
place to put information that a selector is TLS-capable while maintaining
compatibility with existing clients. Most of the proposals either specify a
fixed port (e.g. 4370) which indicates secure-gopher support, or using some
sort of STARTTLS mechanism for opportunistic encryption. There's also a
proposal for a new CAPS.TXT[2] key to enable Gopher Strict Transport Security
for supporting user agents.

[1]: [https://lists.debian.org/gopher-
project/](https://lists.debian.org/gopher-project/)

[2]: gopher://gophernicus.org/0/doc/gopher/gopher-caps.txt

~~~
klez
Why not use different selectors? I mean the first byte of every line in a
menu, can't remember if the name is correct, right now.

~~~
wolfgang42
Selectors are the path to the item on the server, you're thinking of item
types. The problem with that is that existing clients wouldn't know what it
meant. If everyone agreed on this solution, it would probably be all right,
but every server author who's gotten involved in this discussion has a
different solution that they've implemented. Since there's no obviously
superior option, there's no consensus on a standard to settle on and therefore
nobody wants to put the effort into implementing any of the proposals that
aren't their own.

In other words, this is more of a social problem than a technical one: there
are many technical solutions, but deciding on one is proceeding very slowly.

~~~
classichasclass
Client support is really going to be the sticking point, though. No one wants
to put up content no one else is going to view, even in Gopher's relatively
quiet and low-user-count environs.

