Visually Mapping Gopherspace | Hacker News Reader

Visually Mapping Gopherspace

jaruzel.com

63 pointsJaruzel13 comments

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.

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.

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.

Google would never let Veronica take over.

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

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

Any protocol for encrypted gopher?

Gopher basically died once the web arrived, https came after that.

I did find this neat post though about using an encrypted data type for gopher data: https://alexschroeder.ch/wiki/2018-01-10_Encrypted_Gopher

There was a period of time when both coexisted, though. I remember websites that were festooned with Gopher links and a fair bit of content that was only available in Gopher.

Granted, that time was around 1993 or 1994.

Yep for sure. I think https was around 1994, but adoption of it was really really really sparse for probably 10 years if I'm remembering correctly. There was lots of FUD around the overhead.

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/

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

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.

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.

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.

Reply on news.ycombinator.com