Hacker News Reader

Comment by kovac | Hacker News Reader

I'm not a protocol expert. I understand why one would not want to use a subset of HTTP, but why not use the existing, lighter weight gopher protocol instead and implement a server and client that supports TLS for gopher instead? Because TLS being baked into it seems to be the only technical difference between the two protocols.

View on HN

Gopher has split between directory/text. Gemini does not.

Gemini is not so rigorous with formatting as gopher; in Gopher, the different clients can format the paragraphs and do their own thing.

The TLS is the most problematic part, for me; as Gemini decided to go with TOFU, which is IMO horrible in web-like setting; and the TOFU itself is vaguely defined and the specs basically says "client and servers can ignore it or whatever". But it's simple indeed.

Thanks for your points. I agree on the TLS, struck me as odd too. Feel like a gopher(s) would be a nice addition.

While in one sense, it's trivial to transport gopher over TLS, in another sense, it's hard to add because gopher itself has no concept of TLS, and thus a client cannot know from within gopher to use TLS or not. I blogged about this: http://boston.conman.org/2019/03/31.1

Isn't keeping 3rd party stuff like TLS out of the core protocol a good thing? Regarding breaking existing clients in a catastrophic way, I think the server could send an error response to the client that don't support TLS (which is defined in the protocol so the clients should understand the error) if it doesn't want to serve some content without encryption or serve content over port 70 over plain text otherwise? I don't see why old clients are a show stopper there.

Know your market. There's a substantial number of people who use gopher from older computers (think of retro computing). Also, error reporting in the gopher protocol is terrible at best.

Gopher+ makes knowing to use TLS trivial.

Most modern clients default to using TLS and failover to plain text as far as I know.

There are very few, if any Gopher+ servers. And because of that, there are very few clients that support it. And I do see some clients attempting TLS connections to my gopher server, and it clutters the logs with garbage attempts.

I think it is a bit of a chicken and an egg problem. There are a few Gopher+ servers out there (pygopherd gas Gopher+ support for example, which is reasonably widely used), and the Gopher+ protocol is pretty flexible and designed with the metaverse in mind originally (see GopherVR from the original authors).

It is a shame that a lot of current Gopher users seem to be strongly against anything apart from standard Gopher, when the original authors of the protocol had much grander ideas for interactivity & visual interfaces. Sigh.

For anyone interested, the Gopher+ protocol doc never made it to a proper RFC, but is on github in a hyper-linked format to make it easier to read: https://github.com/gopher-protocol/gopher-plus/blob/main/gop...

https://github.com/gopher-protocol/gopher-plus/blob/main/gop... specifically mentions 3D representations of Gopherspace. They also provide provision for a "general purpose" scripting language - I think Javascript would fit the bill - there and in section 2.8

A little off topic, but which gopher server (and any management tools? ) do you use for hosting? I'm in the process of setting up one and trying different ones out but haven't settled on one yet.

I wrote my own gopher server [1] that works for me. I haven't looked at any other gopher servers in any detail to give a recommendation (unless you want to use the one I wrote).

[1] https://github.com/spc476/port70

Reply on news.ycombinator.com