💾 Archived View for gemi.dev › gemini-mailing-list › 000251.gmi captured on 2023-11-04 at 12:36:11. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi all, the next version of deedum is in the play store, I'm also building signed apks in GitHub. This release adds tabs, bookmarks, copy paste, and slightly better connection handling (more below). fdroid and iOS are still on the map, as well as other improvements. The trouble I'm having with some servers is that they do not all seem to close the socket after sending the response, xq on IRC suggested that they may be closing the TLS connection but not the underlying socket. Unfortunately flutter makes this impossible to detect, other than by timeout. Could any server authors chime in here, my read of the protocol is that the socket should be closed? I believe mozz.us and tilde.black, wp.pitr.ca are hosts that behave this way and maybe they aren't using the same server software. Cheers, Case
Happy to see an update! I may have had a related issue, I remember having trouble with redirects on tilde.black and gemini.conman.org. In the end the issue was that they were closing *right after* sending the redirect, I think, and I wasn't capturing the last few bytes. But I was using Go, not Flutter, so I'm not sure how much this helps. makeworld
On Wed, 24 Jun 2020 08:47:40 -0600 case <me at case.codes> wrote: > Hi all, the next version of deedum is in the play store, I'm also > building signed apks in GitHub. > > This release adds tabs, bookmarks, copy paste, and slightly better > connection handling (more below). Hi. I just installed this on my phone. text/gemini content looks good, but text/plain renders in an unreadably small monospace font without wrapping unless manually wrapped to 80 columns before uploading. gemini://tanelorn.city/library/texts/pg2162.txt is OK because it's pre-wrapped, but gemini://starbreaker.org/unfinished/epistolary-outline.txt not so much. -- Matthew Graybosch gemini://starbreaker.org #include <disclaimer.h> gemini://demifiend.org https://matthewgraybosch.com gemini://tanelorn.city "Out of order?! Even in the future nothing works."
Matthew Graybosch <hello at matthewgraybosch.com> wrote: > Hi. I just installed this on my phone. text/gemini content looks good, > but text/plain renders in an unreadably small monospace font without > wrapping unless manually wrapped to 80 columns before uploading. > Everything monospace seems to be fit to the width of the viewport, which might be good for ASCII-art, but not much for text with extreme line lengths. I put together a temporary test page with both short and long examples. => gemini://x-z.se/test.gemini Might move or delete later, but I promise it will still be there at least a few weeks from now. I know next to nothing about Android app making but I feel like fit to width is a reasonable approach for the first versions of the app. Having a min and max text size will be a better user experience in the future. -- Katarina Eriksson >
Thanks for this! I'm planning on adding a couple features for monospace, an option to softwrap and an option to force the width to 40,80,120 chars (if possible, fonts are hard) and a pinch to zoom. For art where you want to zoom in for detail, you'd set softwrap false and trigger a horizontal scroll, whereas plain text might get softwrap set to true. Cheers
It was thus said that the Great colecmac at protonmail.com once stated: > Happy to see an update! > > I may have had a related issue, I remember having trouble with redirects > on tilde.black and gemini.conman.org. In the end the issue was that they > were closing *right after* sending the redirect, I think, and I wasn't > capturing the last few bytes. But I was using Go, not Flutter, so I'm not > sure how much this helps. How did you fix the issue? Or did you? -spc
I worked around it, I found that mozz.us closed the connection properly if I sent a no_write shutdown signal from my side. But doing that on tilde.black caused them to close the connection and not send a response. It happened regardless of redirects as far as I paid attention to that aspect. So, I send the signal, and if I get no response I make the request again without the signal and wait for a timeout... Pretty gross and I'll need to change it eventually since it's no fair to the operators. As implementers tho, I wonder if we shouldn't be working around problems like this (assuming it's on the other side). Should we be strict with out of spec implementations? I feel that the attitude of trying to parse bad html and weird headers is partially what led to the mess in the web early on... But if some clients start working around that stuff, then ones that don't will be considered broken. Jun 24, 2020 2:26:12 PM Sean Conner <sean at conman.org>: > It was thus said that the Great colecmac at protonmail.com once stated: >> Happy to see an update! >> >> I may have had a related issue, I remember having trouble with redirects >> on tilde.black and gemini.conman.org. In the end the issue was that they >> were closing *right after* sending the redirect, I think, and I wasn't >> capturing the last few bytes. But I was using Go, not Flutter, so I'm not >> sure how much this helps. > > How did you fix the issue?? Or did you? > > -spc >
> a no_write shutdown signal Can you clarify more what this is? And more about the difference between your two examples? makeworld
Here's the signal, it indicates to the other side of the connection that no further data will be sent from my side. https://github.com/snoe/deedum/blob/master/lib/net.dart#L169 Here's the retry if the first request with `shutdown: true` comes back empty https://github.com/snoe/deedum/blob/374f6699be936d551cf57a5f2a147eb7ff2193a 7/lib/net.dart#L68 Jun 24, 2020 4:48:19 PM colecmac at protonmail.com: >> a no_write shutdown signal > > Can you clarify more what this is? And more about the difference > between your two examples? > > makeworld >
I run tilde.black. Not sure what's up with the hangup signals. I just have jetforce running on there. It says it's up to date with the latest in pip. If we do go the route of allowing streams this hangup stuff would be relevant there as well, right? I think someone mentioned possibly having a different 2X code for "Success as a stream". That would suggest clients be able to deal with either format? Anyway, what I'm serving now isn't meant to be a stream so it should hang up. If it's not jetforce I'd be happy to work with anyone who knows better about fixing it up on my end. - tomasino
Even with a simple protocol, clients will need to make decisions around handling things gracefully to give users a good experience. The network is fundamentally unreliable, after all! Maybe in these early days client authors can help the community by exposing debug logs. Kind of like when you open dev tools in a browser and you can see warnings for protocol violations or errors. Coleman On Wed, Jun 24, 2020 at 10:21:12PM +0000, Case Nelson wrote: > I worked around it, I found that mozz.us closed the connection properly if I sent a no_write shutdown signal from my side. But doing that on tilde.black caused them to close the connection and not send a response. It happened regardless of redirects as far as I paid attention to that aspect. > > So, I send the signal, and if I get no response I make the request again without the signal and wait for a timeout... Pretty gross and I'll need to change it eventually since it's no fair to the operators. > > As implementers tho, I wonder if we shouldn't be working around problems like this (assuming it's on the other side). Should we be strict with out of spec implementations? I feel that the attitude of trying to parse bad html and weird headers is partially what led to the mess in the web early on... But if some clients start working around that stuff, then ones that don't will be considered broken. > > Jun 24, 2020 2:26:12 PM Sean Conner <sean at conman.org>: > > > It was thus said that the Great colecmac at protonmail.com once stated: > >> Happy to see an update! > >> > >> I may have had a related issue, I remember having trouble with redirects > >> on tilde.black and gemini.conman.org. In the end the issue was that they > >> were closing *right after* sending the redirect, I think, and I wasn't > >> capturing the last few bytes. But I was using Go, not Flutter, so I'm not > >> sure how much this helps. > > > > How did you fix the issue?? Or did you? > > > > -spc > > -- ~coleman
On Wed, Jun 24, 2020 at 08:47:40AM -0600, case wrote: > Could any server authors chime in here, my read of the protocol is that the socket should be closed? I believe mozz.us and tilde.black, wp.pitr.ca are hosts that behave this way and maybe they aren't using the same server software. Your reading of the protocol is correct, servers should be closing the connection at the end of the response. I'm fairly confident that Molly Brown should be doing this under all conditions. This could be something to add to a suite of "server torture tests", something which has been discussed previously on this list but which hasn't yet (correct me if I'm wrong, please!) materialised in a concrete form yet. Cheers, Solderpunk
On Thu, Jun 25, 2020 at 8:58 AM solderpunk <solderpunk at sdf.org> wrote: > This could be something to add to a suite of "server torture tests", > something which has been discussed previously on this list but which > hasn't yet (correct me if I'm wrong, please!) materialised in a concrete > form yet. > There is the start of a server torture test at https://github.com/michael-lazar/gemini-diagnostics
There is already at least one test for server not closing connection - gemini://egsam.pitr.ca/1.1.gmi On Thu, Jun 25, 2020 at 8:22 PM Matt Brubeck <mbrubeck at limpet.net> wrote: > > > > On Thu, Jun 25, 2020 at 8:58 AM solderpunk <solderpunk at sdf.org> wrote: >> >> This could be something to add to a suite of "server torture tests", >> something which has been discussed previously on this list but which >> hasn't yet (correct me if I'm wrong, please!) materialised in a concrete >> form yet. > > There is the start of a server torture test at > > https://github.com/michael-lazar/gemini-diagnostics >
On Wed, Jun 24, 2020 at 06:22:12PM +0000, Case Nelson wrote: > Thanks for this! Glad I could help, and I'm glad to hear about the upcoming features. In the meantime I'm going to hard-wrap anything that isn't text/gemini for maximum compatibility. It's not hard to do since my main editor is Emacs. I'll be watching for updates so I can explore geminispace from the comfort of my bathroom. :) -- Matthew Graybosch gemini://starbreaker.org #include <disclaimer.h> gemini://demifiend.org https://matthewgraybosch.com gemini://tanelorn.city "Out of order?! Even in the future nothing works."
On 25/6/20 12:47 am, case wrote: > Hi all, the next version of deedum is in the play store, I'm also building signed apks in GitHub. > > This release adds tabs, bookmarks, copy paste, and slightly better connection handling (more below). > > > fdroid and iOS are still on the map, as well as other improvements. > > > The trouble I'm having with some servers is that they do not all seem to close the socket after sending the response, xq on IRC suggested that they may be closing the TLS connection but not the underlying socket. Unfortunately flutter makes this impossible to detect, other than by timeout. > > Could any server authors chime in here, my read of the protocol is that the socket should be closed? I believe mozz.us and tilde.black, wp.pitr.ca are hosts that behave this way and maybe they aren't using the same server software. > > Cheers, > Case > G'day Case, Thanks for your work on building and releasing deedum, has been great to use from my phone :) I'm uncertain if the problem I'm seeing is from deedum or my gemsite. when I go to gemini://gem.pwarren.id.au/ in deedum I get "AN error ocurred INTERNAL EXCEPTION -------------- Handshake error in client " It's served by gemserve. I recently switched over to ed25519 certs recently, which may point to the problem! av98 and kristall on linux don't seem to have any issues (After telling them that the new cert is OK), and openssl reports everything is OK. Is there a way of getting more detailed info out of deedum? -- Paul
Hi Paul, Your suspicion about the new cert is correct. I've been looking for a way to support it but it seems Flutter is just behind on TLS. I may be able to drop to Dalvik/java and CryptoKit but that's a big jump in complexity and I'm still asking around the flutter community for a hand solving it. If anyone has pointers I'd appreciate it. I'd love to support it in deedum but I fear it's getting into "don't implement crypto" territory. Sadly Flutter is easy but not simple, and TLS libraries are similar. Gemini's support of TLS 1.2 seems to have stemmed from this issue and I thought the thread about the new algos came to a similar conclusion; it would be nice to use everywhere but libraries aren't caught up. --- Case
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 6/24/2020 7:47 AM, case wrote: > Hi all, the next version of deedum is in the play store, I'm also > building signed apks in GitHub. > > > fdroid and iOS are still on the map, as well as other > improvements. Hi :) Any progress on deedum being available at F-Droid yet? I tend not to sideload too much, and avoid Google's Playstore at every turn I can. I also just did another search at F-Droid for "Gemini" coming up with nothing. Are there other Gemini clients and utils for Android I might find there or elsewhere? - -- Bradley D. Thornton Manager Network Services Gemini://VGer.Cloud TEL: +1.310.421.8268 -----BEGIN PGP SIGNATURE----- Comment: Find this cert at hkps://keys.openpgp.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAl8BOawACgkQuIw5wQyt yEkyJQgAoFAjdkCW8f8qVxajL22ojvRyjX48FrtwmEwhuv/Yx3jYm4JDC3o6J5IQ gZndd7d7rayP0HVnPO21g1UI85ugFcToJLJdRxH+wklFsrZ2aNO4mPUrr08fafTq wxXSY8mGKhjEul0dNvC5uu9IDnviXvIUt4XKkk9GqcfA5byYr2UEk/34FGnxh1Ju mUMTlwUjp45t7paVyRxkmmdIioJYCAIl3SQpjEvEPkAMsK3LKi83QS/neZt/s6O6 NEjA3tVpiJIgmpZZFMxNQ3COHd01Cryfp59FpX4G47iFNLlKlBxEJVgYVidWblcA kkadVehh1l4BrohTSKDoSrF6pSJG/Q== =xdm2 -----END PGP SIGNATURE-----
Hi, there's some progress for fdroid: Here's the tracking ticket: https://gitlab.com/fdroid/rfp/-/issues/1404 Here's a repo where it's available before it gets pulled into main (iiuc): https://apt.izzysoft.de/fdroid/index/apk/ca.snoe.deedum Cheers, Case
---
Previous Thread: [ANN] tinmop, a pleroma client includes a gemini viewer