Fwd: elpher now supports gemini

[Bradley D. Thornton]

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