4 ms·

Any protocol for encrypted gopher?

codezero 9y ago
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 https://alexschroeder.ch/wiki/2018-01-10_Encrypted_Gopher
- classichasclass 9y ago
  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.
  - codezero 9y ago
    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.
wolfgang42 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.

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 https://alexschroeder.ch/wiki/2018-01-10_Encrypted_Gopher

classichasclass 9y ago
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.
- codezero 9y ago
  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.

wolfgang42 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.