1. 16

  2. 6
    1. 1

      Yeah, gopher encryption is a hot topic in the gopher space, so you’re not the only one. Rain, solderpunk, & I have been arguing about it for a while…

      1. 1

        I remember this. I’ve actually got a gopher+TLS listening on 7443 but no one talks to it currently, primarily for the reasons of service discovery you mention, I would imagine.

        I think gopher is a good fit for retrocomputing and those would be the systems least likely to use TLS. Maybe the solution is something new that still keeps the menus and all that, as you suggest.

        1. 1

          I’m also not aware of any gopher clients that talk TLS—I know mine doesn’t [1]. What’s the host? I’d be interested in trying it out.

          [1] But it could be easily added, as the Lua framework I’m using supports TLS.

          1. 3

            I’m also not aware of any gopher clients that talk TLS



            1. 1

              The very host proxying this post. :)

              I have a very rudimentary proof of concept browser that essentially keeps a history, tries 7443 first, and then 70, and remembers for future connections. I’m not sure this is the right approach but I can’t think of a better one right now.

              1. 1

                What host is proxying your post?

                1. 1

                  I was trying to be cute but I think I failed. I mean the host proxying what rain1 wrote, i.e., Floodgap.

                  1. 1

                    Ah. I tried it out and yes, it worked. But it was a temporary hack to my gopher client, and I’m not sure how I would go about supporting this.

        2. 3

          I don’t know if encrypting gopher would be a good idea.

          In HTTP encryption is made for the purpose of protecting authentication credential and communication privacy, but isn’t this requirement just coming from the fact we abuse HTTP in every possible way?

          Gopher is made for showing a publicly available hierarchy of menus and files.

          And yes, there’s the privacy concern of the provider/government/whatever snooping on your gopher requests and responses. But if that is a concern, wouldn’t other protocols better suited for private communication?

          1. 5

            Private by default is a social expectation, not merely a technical one; in short, we encrypt things for the same reason we send almost all mail in envelopes, and we don’t shout our conversations in public spaces.

            1. 3

              Heresy! Encrypt all the things!

              (I’m one of those weirdos who’s still not convinced that plain static website content really needs encryption, but I realize the arguments against that idea are many and hold their water pretty well.)

            2. 1

              TLS with Gopher is probably the only way that you can host multiple gopher sites per IP address.

              1. 3

                Or virtual hosts based on hostname. Or different ports. Encryption is not required for that.

                1. 2

                  Gopher doesn’t have the concept of vhosts. If the client supports SNI, the server can use that to approximate vhosts.

                  1. 3

                    Gopher doesn’t have TLS, either. If we’re going to add something, we could add anything.

                  2. 1

                    I’m going under the assumption that nobody is going to care enough to make their clients or URIs use alternate ports. People have a hard enough time remembering names of things.

                    1. 1

                      Maybe for gateways. Maps supply port numbers, so once the user is navigating they don’t need to worry.

                      What’s the point of having multiple sites on the same host? Overloading the meaning of the same identifier string?

                      1. 1

                        Mostly so there’s a logical separation between my personal website and other things like When Then Zen and my Go Remote Import/Vanity Import server.

                        1. 2

                          Fair enough.

                          I think that, to the extent that there’s an idiomatic gopher way to handle this, it’s the same as pre-vhost HTTP: i.e., pretend there’s a directory hierarchy (whether or not there really is – gopher actually just exposes a string-keyed hash table of strings, but gopher servers generally default to wrapping an actual filesystem like HTTP servers do) & have different sections as subdirectories (or as string prefixes, if you aren’t exposing an actual filesystem).

                          Port numbers solve the problem, but not well because they aren’t meaningful.

                          Of course, you could always have different IPs associated with different subdomains & route the requests to different tables (i.e., roll your own pseudo-vhost)…

                  3. 3

                    I’m imagining an alternative history in which Gopher beat out HTTP, so the lack of a Host header caused them to rush out full IPv6 deployment decades ahead of us. SNI never needed to be invented in that universe.

                    It’s not all good though, the hypothetical gophers with the 128 bit addresses never invented the Hampster Dance.