4 ms·
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
by 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 agoWhy 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 agoSelectors 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 agoClient 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.