Comment by 👻 ps
and what about gemin://
:D seriously
Feb 27 · 2 months ago
15 Later Comments ↓
🍀 gritty [OP] · Feb 27 at 12:39:
@skyjake thanks that helps
Plural of gopher?
@ps I think that is called spartan://
MrSVCD, nope see geminict://
🐙 norayr [mod] · Mar 03 at 00:07:
what is that? mix of DICT and gemini?
I think geminict:// is the Gemini protocol without TLS; I think they wanted to use a different default port number than Gemini with TLS, although I had thought it would be better to use the same port number (gophers:// and scorpions:// also use the same default port numbers as the corresponding non-TLS protocols; since it starts with ASCII and client first, this will work, unlike some other protocols that cannot work this way because the server is first).
(Spartan is a different protocol, although the Gemini file format is used (with one difference for requesting input).)
I've been talking about Gemini -tls for years, and even got yelled at for doing so.
🍀 gritty [OP] · Mar 08 at 16:21:
In case you're curious, VF-1 by @solderpunk supports gophers://
— Example gophers:// link on bitreich
Are there many gophers:// sites? I wonder if this is worth implementing.
🍀 gritty [OP] · Mar 08 at 16:50:
I'm not sure. The only ones I've found are on bitreich so far and I don't know much else about it. It's not officially supported, but it *appears* bitreich is an active community / gopherhole that uses it, so I'm unsure.
FWIW, browser support seems to accelerate adoption of standards
Here's a few more:
— gophers://bitreich.org/1/bay
— gophers://bitreich.org/1/xml-stri-club
— gophers://bitreich.org/1/progress-bar
— gophers://bitreich.org/1/space-bar
@bluesman - If you do end up including it, getting bitreich (and a few other central places) to list a link to your browser would probably help
@gritty Hey! I got it working. Got stuck for a bit because it needs to listen for CLOSE_NOTIFY when using gophers://. I'll test some more and commit the code later tonight. Otherwise, it will be in release 5.5.3.
The interesting thing is that it appears all URLs to hosts that support gophers:// work with and without TLS. Two examples: bitreich.org and gopherproject.org.
The issue(?) is that if you access gopherproject.org using the TLS protocol, most if not all of the gopherproject.org URLs on the returned page are non-TLS. It seems the browser should detect when you use gophers:// and then continue to use TLS for all subsequent URLs to the same host regardless of whether they are gophers:// or gopher://. Is there a reason not to do this? It would only break things if a host selectively allowed gophers:// to certain resources.
I think that most URLs should work with both TLS and non-TLS (with the exception of files requiring user authentication, so those files (only) might require TLS), so that is not wrong; there dies not seem to be much point for disallowing TLS for some files even though other files on the same server do allow TLS. However, as I had mentioned elsewhere, the gopher menu format does not indicate if it is TLS or not. Links to the same host and port could use TLS or not depending on the current URL, but for external links, DNS records could be used to decide. There could be a user configuration setting to control this feature.
🍀 gritty [OP] · Mar 09 at 19:27:
yeah I'm not really sure why. There isn't really an official spec so maybe this wasn't considered.
@zzo38 Right. I forgot the gopher menu format can't specify TLS. I might just do a host-based thing for now. It appears there's a gopher client that does TOFU. Always something.
Original Post
what is "gophers://" ?