💾 Archived View for gemi.dev › gemini-mailing-list › 000013.gmi captured on 2024-08-31 at 15:27:01. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

Fwd: elpher now supports gemini

1. Jason McBrayer (jmcbray (a) carcosa.net)

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

Link to individual message.

2. plugd (plugd (a) thelambdalab.xyz)

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..)

Link to individual message.

3. Bradley D. Thornton (Bradley (a) NorthTech.US)



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

Link to individual message.

4. plugd (plugd (a) thelambdalab.xyz)

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:



The following I can't connect to at all (i.e. no server response):


I cross-checked with AV-98 and got the same results.

Link to individual message.

5. James Tomasino (tomasino (a) lavabit.com)

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.

Link to individual message.

6. Sean Conner (sean (a) conman.org)

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.

Link to individual message.

7. Sean Conner (sean (a) conman.org)

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 ... )

Link to individual message.

8. plugd (plugd (a) thelambdalab.xyz)

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/


plugd

Link to individual message.

9. solderpunk (solderpunk (a) SDF.ORG)

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

Link to individual message.

10. plugd (plugd (a) thelambdalab.xyz)


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!

Link to individual message.

---

Previous Thread: Best practices in Gemini servers

Next Thread: [ANN] GLV-1.12556 Gemini Server now released