Elpher, an emacs gopher client by lambdalabs, now supports Gemini. I saw the announcement here: gopher://thelambdalab.xyz:70/0/phlog/2019-09-11-Elpher-now-supports-Gemini.txt The project page is here: gopher://thelambdalab.xyz/1/projects/elpher/ Just to note, I'm not the author, though I've been a user of it since its initial release. -- Jason McBrayer jmcbray at carcosa.net ?Strange is the night where black stars rise, and strange moons circle through the skies, but stranger still is lost Carcosa.? ? Robert W. Chambers,The King in Yellow
Hi Jason, Jason McBrayer writes: > Elpher, an emacs gopher client by lambdalabs, now supports Gemini. I > saw the announcement here: Thanks for posting this. As I pointed out in that post the Gemini support is still highly "experimental". (I mean, there are only a handful of servers out there to test it on - hopefully this will change!) So feedback is hugely welcome. > Just to note, I'm not the author, though I've been a user of it since > its initial release. Nice to hear! Feel free to send me any thoughts you have on the new release. Cheers, plugd/lamdalabs/tim/whatever (I'm going through a bit of a phlogosphere identity crisis here..)
On 9/12/2019 12:02 AM, plugd wrote: > Hi Jason, > > Jason McBrayer writes: > >> Elpher, an emacs gopher client by lambdalabs, now supports Gemini. I >> saw the announcement here: > > Thanks for posting this. As I pointed out in that post the Gemini > support is still highly "experimental". (I mean, there are only a > handful of servers out there to test it on - hopefully this will > change!) So feedback is hugely welcome. > This is a really nice client, aside from the ability to easily check the source that is served using the "." binding, and that's golden when testing. I was thrown off a bit when I brought up zaibatsu and didn't recognize anything - when you wear one lense, you won't see what you already know because you're not looking through the lense that sees another aspect. Then it dawned on me that I was looking at a gophermap, so I figure it's a Gegobi server. Pretty kewl how it does that. The thing I like most about it includes my hope that my fav Gopher clients integrate seamless Gemini support as you have. When I first installed and fired it up, I stupidly made the assumption that, like most of the Gemini clients, I could just ask for the hostname and the URI would wrap it - duh! No! Obviously, because as soon as I typed in the hostname of my server the Gopher site came up instead of the Gemini site - as it should. It's not a big deal prepending gemini:// anyway. I do wish it was easier to determine the URL I'm currently at though. That will take some getting used to not having it prominently displayed. I made some observations and took some notes about the various servers, and some of URLs being served up as well. First, before anyone starts looking at what might be askew with the servers, I need to say that while using the other Gemini client that I like so far, all sites come up with no problem at all in Asuka. 1.) Okay first, I get a lot of this in Elpher: <snip> ---- ERROR ----- When attempting to retrieve gemini://vger.cloud: Gemini server reports PERMANENT FAILURE for this request. ---------------- Press 'u' to return to the previous page. </snip> 2.) I experienced problems with gemini.conman.org loading beyond 1%. 3.) zaibatsu.circumlunar.space comes up, but it takes a while. Like I said above, in Asuka, all sites come up rather quickly, although I can tell the difference in the resources being served. In Elpher it can take several seconds, however. A feature of Elpher that I find really kewl is that it doesn't presume it's okay to just plough ahead when it perceives there's something funky with the cert, as illustrated in this image (I'm unable to select this text in Elpher to paste it, if there's a way, please enlighten me): https://bit.ly/2kKJCrv That originally came up for gemini://conman.org (certificate/host mismatch), because that's NOT the hostname the cert was issued for. Again, Asuka and the other clients don't complain, but prolly should ;) No warning when entering the correct URL of gemini://gemini.conman.org If I reject the certificate for zaibatsu here's the server response I get: <snip> ---- ERROR ----- When attempting to retrieve gemini://zaibatsu.circumlunar.space: Wrong type argument: processp, nil. ---------------- Press 'u' to return to the previous page. </snip> It would be nice if Elpher would return the actual two-digit Gemini error codes. 4.) gemini://carcosa.net - The only thing I can say is that it comes up fast as lightning. 5.) gemini://heavysquare.com - very fast, but I do get the cert warning saying it was signed by sectigo, a CA I've never heard of. That cert warning in Elpher is really nice, if I haven't said so already! 6.) gemini://mozz.us - I get the following, and again, it would be nice if Elpher displayed the actual two digit error codes. I've been running Jetforce too, and my server uses a LetsEncrypt cert, so no surprise that even though the connections are refused, there's no cert warning in Elpher for either servers. <snip> ---- ERROR ----- When attempting to retrieve gemini://mozz.us: Gemini server reports PERMANENT FAILURE for this request. ---------------- </snip> I can't help but wonder if this is because of an AAAA RR? My Jetforce server is currently listening on 0.0.0.0 and I'm not sure if I can put "::" in the startup script's configs like Sean mentioned earlier. 7.) gemini://dgold.eu - refuses the connection as well. 8.) gemini://typed-hole.org - I don't know which one's faster in responding, this one or carcosa. I get a permanent failure on the links to the games in Elpher, but the guestbook and lobst.rs links work fine. This is a Pollux server. 9.) gemini://consensus.circumlunar.space - Connection refused (I could swear it came up for me before in Elpher). <snip> ---- ERROR ----- When attempting to retrieve gemini://consensus.circumlunar.space: make client process failed: Connection refused, :name, elpher-process, :buffer, #<killed buffer>, :host, consensus.circumlunar.space, :service, 1965, :nowait, nil, :tls-parameters, nil. ---------------- </snip> 10.) tilde.black and tilde.pink - both servers return Permanent failure. Elpher warns of a self-signed cert for tilde.pink (I'm don't remember, but I may have cached the cert with an "a" for tilde.black). I haven't tried either of those with Asuka yet, they've only been listed for less than a week. As far as the IPv4/IPv6 issue, I don't really think most of those options should really be left to the author of the client software to tackle, and think server support for binding "::" to the NIC to be the best solution. Alternately, perhaps temporarily dropping the AAAA RR temporarily, until the Gemini server supports IPv6 bindings, if there aren't other services listening on the host. I may have missed a few things here and there, but this is all really just the result of playing around with Elpher, which, if I'm not really careful, might get me to start saying nice things about Emacs ;) I hope that helps :) -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
Hi Bradley, Wow - I didn't expect such a detailed usage report! Thank you very much, this is incredibly useful. I will go through all of your comments in detail later. But at the moment I want to rush out a quick reply to point out that some of the "Gemini server reports PERMINANT FAILURE" errors might have been due to a bug in the URL processing code. I was mishandling the (important!) edge case where the filename portion is empty, resulting in broken URLs being sent to servers. This should now be fixed. I agree that the the failed connection errors need cleaning up a bit. I'm not sure what's causing zaibatsu to load slowly for you. In my case at the moment it's due to the IPv6 issues that I mentioned earlier. (It turns out that Emacs _does_ eventually fall back to the IPv4 address, but only after a whole _minute_ or so of waiting.) Is it possible that your experience is just due to elpher not rendering anything until the entire document is available? (I would prefer not to have to do this, but I'm not smart enough to figure out how to do this without breaking a lot of the things I like about the current factoring of the code.) Regarding the cert verification stuff: I'd love to take credit for this but it is in fact just Emacs' defualt GnuTLS behaviour. At some point I hope to change this to reflect solderpunk's TOFU suggestion, as I expect it'd get annoying when there are upwards of 100 or 1000 gemini servers with different self-signed certificates. Hopefully your server (which I don't think I'd stumbled on before) should be accessible now following the URL parsing fixes. I've also added the URL of the current page to the header in the latest release, so hopefully this also reduces confusion somewhat. > As far as the IPv4/IPv6 issue, I don't really think most of those > options should really be left to the author of the client software to > tackle, and think server support for binding "::" to the NIC to be the > best solution. Alternately, perhaps temporarily dropping the AAAA RR > temporarily, until the Gemini server supports IPv6 bindings, if there > aren't other services listening on the host. I'm starting to think that this is more of an emacs networking issue. While the problem does manifest with, for instance, AV-96, it's not nearly as severe - there's "only" a 10-20s delay in the connection, compared with a whole minute in emacs. If only there were a way of altering the default timeout used by emacs... > I may have missed a few things here and there, but this is all really > just the result of playing around with Elpher, which, if I'm not really > careful, might get me to start saying nice things about Emacs ;) Be careful, it's a slippery slope... :-P > I hope that helps :) It absolutely does!! plugd p.s. with the current release I have no problems with the following servers:
On 9/13/19 4:42 PM, plugd wrote: > p.s. with the current release I have no problems with the following > servers: > > * gemini://vger.cloud/ > ... > > The following I can't connect to at all (i.e. no server response): > * gemini://gopher.black/ > * gemini://consensus.circumlunar.space/ > * gemini://dgold.eu/ gopher.black is not currently running a gemini server. It was only a short-term test. It may return, but don't let it cloud your test results.
It was thus said that the Great Bradley D. Thornton once stated: > > 2.) I experienced problems with gemini.conman.org loading beyond 1%. What type of problem? I've been making a lot of changes to the server code recently and there might be issues that aren't client releated but server releated. > 3.) zaibatsu.circumlunar.space comes up, but it takes a while. Like I > said above, in Asuka, all sites come up rather quickly, although I can > tell the difference in the resources being served. In Elpher it can take > several seconds, however. Of the servers, I get: gemini://gemini.conman.org/ comes up quick [1] gemini://zaibatsu.circumlunar.space/ comes up quick gemini://carcosa.net/ comes up quick gemini://heavysquare.com/ comes up quick gemini://mozz.us/ comes up quick gemini://dgold.eu/ error: cannot connect to dgold.eu gemini://typed-hole.org/ comes up quick gemini://gopher.black/ (gone---mentioned in another email) gemini://tilde.black/ comes up quick gemini://consensus.circumlunar.space/ error: cannot connect to consensus.circumlunar.space gemini://tilde.pink/ comes up quick gemini://165.22.178.247/ comes up quick (but returns status 51) gemini://vger.cloud/ comes up quick And of certificates: gemini://gemini.conman.org/ unknown CA [2] gemini://zaibatsu.circumlunar.space/ self-signed gemini://carcosa.net/ self-signed gemini://heavysquare.com/ unknown CA gemini://mozz.us/ valid gemini://dgold.eu/ N/A (can't connect) gemini://typed-hole.org/ self-signed gemini://gopher.black/ N/A (gone) gemini://tilde.black/ valid gemini://consensus.circumlunar.space/ N/A (can't connect) gemini://tilde.pink/ self-signed gemini://165.22.178.247/ self-signed gemini://vger.cloud/ valid > A feature of Elpher that I find really kewl is that it doesn't presume > it's okay to just plough ahead when it perceives there's something funky > with the cert, as illustrated in this image (I'm unable to select this > text in Elpher to paste it, if there's a way, please enlighten me): > https://bit.ly/2kKJCrv > > That originally came up for gemini://conman.org (certificate/host > mismatch), because that's NOT the hostname the cert was issued for. Yup. I don't know how to create a certificate for multiple hostnames. > Again, Asuka and the other clients don't complain, but prolly should ;) Probably, but if you aren't doing certificate validation (to get around the whole "self-signed" thing, perhaps it's a moot point?) -spc [1] It better for me. I wrote the server. [2] I have my own private CA I signed the certificate with.
It was thus said that the Great plugd once stated: > p.s. with the current release I have no problems with the following > servers: > > * gemini://vger.cloud/ > * gemini://tilde.black/ > * gemini://tilde.pink/ > * gemini://carcosa.net/ > * gemini://heavysquare.com/ > * gemini://mozz.us/ > * gemini://typed-hole.org/ > * gemini://zaibatsu.circumlunar.space/ > > The following I can't connect to at all (i.e. no server response): > * gemini://gopher.black/ > * gemini://consensus.circumlunar.space/ > * gemini://dgold.eu/ > > I cross-checked with AV-98 and got the same results. You're missing <gemini://gemini.conman.org> from that list. -spc (I'm just saying ... )
Sean Conner writes: > You're missing <gemini://gemini.conman.org> from that list. Woops! The funny thing is that it's only missing because I was ticking off the links listed at the bottom of _your page!_ :-) But for completeness, here's the _complete_ list of elpher-approved servers: > * gemini://vger.cloud/ > * gemini://tilde.black/ > * gemini://tilde.pink/ > * gemini://carcosa.net/ > * gemini://heavysquare.com/ > * gemini://mozz.us/ > * gemini://typed-hole.org/ > * gemini://zaibatsu.circumlunar.space/
Many overdue thanks Jason for sharing this announcement here and to plugd for adding Gemini support! I've gone ahead and added elpher to the list of clients at my Gemini gopher page. -Solderpunk
solderpunk writes: > Many overdue thanks Jason for sharing this announcement here and to > plugd for adding Gemini support! I've gone ahead and added elpher to > the list of clients at my Gemini gopher page. Thanks! And don't forget Sean's GLV-1.12556 server he announced a few days ago! plugd p.s. just noticed Zaibatsu is in the process of being "gegobi"ed - cool!
---