💾 Archived View for gemi.dev › gemini-mailing-list › 000277.gmi captured on 2023-11-04 at 12:38:09. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Did I miss the mention in this group? https://news.ycombinator.com/item?id=23730408 I saw lot of idle "concern" about viability and bike shedding, some actual interest. Participated a little myself... On July 4, 2020 4:01:43 PM PDT, gemini-request at lists.orbitalfox.eu wrote: >Send Gemini mailing list submissions to > gemini at lists.orbitalfox.eu > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.orbitalfox.eu/listinfo/gemini >or, via email, send a message with subject or body 'help' to > gemini-request at lists.orbitalfox.eu > >You can reach the person managing the list at > gemini-owner at lists.orbitalfox.eu > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Gemini digest..." > > >Today's Topics: > > 1. Re: Ditching mandatory TLS (Sean Conner) > 2. Re: Ditching mandatory TLS (solderpunk) > 3. Re: URL/META length (solderpunk) > 4. Re: Ditching mandatory TLS (Sean Conner) > 5. Re: Ditching mandatory TLS (solderpunk) > 6. Re: URL/META length (Phil Leblanc) > 7. Re: URL/META length (solderpunk) > 8. =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini? > (traderbeckola at tahoma.com) > 9. Re: What?s considered proxying in Gemini? (solderpunk) > 10. Re: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini? > (traderbeckola at tahoma.com) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 4 Jul 2020 17:12:17 -0400 >From: Sean Conner <sean at conman.org> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: Ditching mandatory TLS >Message-ID: <20200704211217.GT19717 at brevard.conman.org> >Content-Type: text/plain; charset=us-ascii > >It was thus said that the Great Drew DeVault once stated: >> Unpopular opinion time: Gemini should not have mandatory TLS. >> >> - TLS is not conveinent for local development >> - TLS is inherently dependent on a centralized oligarchy of CAs >> - Baking TLS into the protocol is going to be a bad look when The >Next >> TLS comes out >> - Some alternative modes of internet access have built-in encryption >> guarantees: yggdrasil, cjdns, Tor; and for these adding TLS is >> redundant (and arguably worse) > > I won't argue that TLS is a bad choice, but before throwing out >alternatives like yggdrasil, cjdns or noise, instead *just implement >the >damn thing* [1][2]---write both a Gemini server and client (for bonus >points---implement ALL THE ENCRYPTIONS!) so the rest of us can see how >easy >it is, and *then* we can have an actual discussion about transitioning >away >from TLS (or including other mechanisms). > > This has already been done once: > > https://lists.orbitalfox.eu/archives/gemini/2020/000457.html > >and the follow-up: > >> #### About my previous proposal >> >> I'll have to think harder about it (within my limited cryptographic >> expertise), and perhaps submit it to a cryptographers community for >> feedback. >> >> At the moment I can see only a minor privacy flaw in it: the client >> discloses its identity (and proof of identity) to any server; >instead >> it should first wait for the server to disclose its identity (and >> proof of identity) before proceeding. >> >> This issue stems from the fact that the ransport_prepare function >> is "symmetrical" and tries to reduce network round-trips; instead >the >> client could first wait for the server verifier and then send its own >> (i.e. just a minor change to that function). > > (https://lists.orbitalfox.eu/archives/gemini/2020/000477.html) > > -spc (Note: not much from Ciprian since then ... ) > >[1] I disagreed with solderpunk about the status codes when he first > proposed Gemini. In stead of hashing it out over months, I just > went ahead and wrote a Gemini server with the status codes I thought > it should have. We then spent a few months hashing it out, but at > least there was an implementation (or two by the time the discussion > came to an end) backing up the argument(s). > >[2] This applies to anyone, not just Drew. > > >------------------------------ > >Message: 2 >Date: Sat, 4 Jul 2020 21:24:03 +0000 >From: solderpunk <solderpunk at SDF.ORG> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: Ditching mandatory TLS >Message-ID: <20200704212403.GC5368 at SDF.ORG> >Content-Type: text/plain; charset=us-ascii > >On Sat, Jul 04, 2020 at 05:12:17PM -0400, Sean Conner wrote: > >> I won't argue that TLS is a bad choice, but before throwing out >> alternatives like yggdrasil, cjdns or noise, instead *just implement >the >> damn thing* [1][2]---write both a Gemini server and client (for bonus >> points---implement ALL THE ENCRYPTIONS!) so the rest of us can see >how easy >> it is, and *then* we can have an actual discussion about >transitioning away >> from TLS (or including other mechanisms). > >I don't really know much about cjdns or noise, but Yggdrasil just looks >like an ordinary IPv6 tunnel and requires nothing special from >software. >There is actually already at least one Gemini server on the public >Yggdrasil network. The admin is also an AV-98 user and I assume he's >using it without any modification. I plan to experiment with this >myself, someday... > >Cheers, >Solderpunk > > >------------------------------ > >Message: 3 >Date: Sat, 4 Jul 2020 21:33:46 +0000 >From: solderpunk <solderpunk at SDF.ORG> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: URL/META length >Message-ID: <20200704213346.GD5368 at SDF.ORG> >Content-Type: text/plain; charset=us-ascii > >On Sat, Jul 04, 2020 at 07:17:37PM +0000, Phil Leblanc wrote: > >> > Can we solve a lot of these issues by bumping up our maximum URL >length? >> >> I suggest bumping the URL maximum length to 8KB. >> >> - it allows creative uses of _mechanisms already in place_ in Gemini, >> - it doesn't change the definition of the protocol and protocol >elements, >> - it doesn't impact existing clients, >> - the impact on existing servers is very limited (allocating a 8K >> instead of 1K buffer...), and an existing server should just refuse >> too long a request. >> - 8K vs 1K doesn't make a difference for a client today in terms of >> RAM footprint - after all, let's not forget that TLS is mandatory >here >> ;-) > >I'm still open to something like this. And for the record, I still >think the idea of "uploading by hosting" and passing the URL used for >that in response to a status code 10 is too beautiful not to explore, >if >we really, really need to be able to upload in band. I get that not >everybody can host publically, but this could be worked around in >various ways: pubnixes could offer this facility to their users. >Somebody could setup a lightweight public web upload point which >then rehosted the resource one a one-use Gemini URL - Sloum has already >demonstrated with gemlog.blue how this kind of thing can work. > >Cheers, >Solderpunk > > >------------------------------ > >Message: 4 >Date: Sat, 4 Jul 2020 17:56:19 -0400 >From: Sean Conner <sean at conman.org> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: Ditching mandatory TLS >Message-ID: <20200704215618.GU19717 at brevard.conman.org> >Content-Type: text/plain; charset=us-ascii > >It was thus said that the Great solderpunk once stated: >> On Sat, Jul 04, 2020 at 05:12:17PM -0400, Sean Conner wrote: >> >> > I won't argue that TLS is a bad choice, but before throwing out >> > alternatives like yggdrasil, cjdns or noise, instead *just >implement the >> > damn thing* [1][2]---write both a Gemini server and client (for >bonus >> > points---implement ALL THE ENCRYPTIONS!) so the rest of us can see >how easy >> > it is, and *then* we can have an actual discussion about >transitioning away >> > from TLS (or including other mechanisms). >> >> I don't really know much about cjdns or noise, but Yggdrasil just >looks >> like an ordinary IPv6 tunnel and requires nothing special from >software. > >If that's the case for Yggdrasil, then you are *still* using TLS over >it >(and it's not a replacement for TLS). > > -spc > > > >------------------------------ > >Message: 5 >Date: Sat, 4 Jul 2020 21:59:44 +0000 >From: solderpunk <solderpunk at SDF.ORG> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: Ditching mandatory TLS >Message-ID: <20200704215944.GG5368 at SDF.ORG> >Content-Type: text/plain; charset=us-ascii > >On Sat, Jul 04, 2020 at 05:56:19PM -0400, Sean Conner wrote: > >> > I don't really know much about cjdns or noise, but Yggdrasil just >looks >> > like an ordinary IPv6 tunnel and requires nothing special from >software. >> >> If that's the case for Yggdrasil, then you are *still* using TLS >over it >> (and it's not a replacement for TLS). > >You're right, it's not a replacement - running Gemini without TLS over >Yggdrasil would break any client certificate apps. No alternative is >going to keep those working. TLS is baked in pretty deep. > >Cheers, >Solderpunk > > >------------------------------ > >Message: 6 >Date: Sat, 4 Jul 2020 21:59:23 +0000 >From: Phil Leblanc <philanc at gmail.com> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: URL/META length >Message-ID: > <CAOH6EB_GDzfkMcn8zssLmmuAneYSPFxg7DNZma+Xvd7ifgXAGg at mail.gmail.com> >Content-Type: text/plain; charset="UTF-8" > >On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote: > >> > > Can we solve a lot of these issues by bumping up our maximum URL >length? >> >> I'm still open to something like this. And for the record, I still >> think the idea of "uploading by hosting" and passing the URL used for >> that in response to a status code 10 is too beautiful not to explore, >if >> we really, really need to be able to upload in band. > >A longer URL doesn't prevent at all exploring / implementing the >uploading by hosting approach. It only addresses some use cases where >the existing input mechanism can be used as-is (e.g. comments, small >document updates). > >I think it could also be useful for simple gemini applications, >typically the applications "by me, for me" you describe here >=>gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-f or-gemini-applications.gmi > >It is _not_ a modification in any way of the Gemini protocol - Just a >different size limit. > >Phil > > >------------------------------ > >Message: 7 >Date: Sat, 4 Jul 2020 22:14:37 +0000 >From: solderpunk <solderpunk at SDF.ORG> >To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> >Subject: Re: URL/META length >Message-ID: <20200704221437.GH5368 at SDF.ORG> >Content-Type: text/plain; charset=us-ascii > >On Sat, Jul 04, 2020 at 09:59:23PM +0000, Phil Leblanc wrote: >> On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote: >> >> A longer URL doesn't prevent at all exploring / implementing the >> uploading by hosting approach. It only addresses some use cases where >> the existing input mechanism can be used as-is (e.g. comments, small >> document updates). >> >> It is _not_ a modification in any way of the Gemini protocol - Just a >> different size limit. > >Sure, I get all that, didn't mean to imply otherwise. > >Just doing "my thing" of urging people to think hard about and perhaps >even actually implement and test solutions to problems which don't >involve extension/modification in preference to those which do... > >Cheers, >Solderpunk > > >------------------------------ > >Message: 8 >Date: Sat, 4 Jul 2020 18:33:58 -0400 >From: traderbeckola at tahoma.com >To: gemini at lists.orbitalfox.eu >Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini? >Message-ID: <39802f4e-8f27-4474-a406-ee782a60df55 at Spark> >Content-Type: text/plain; charset="utf-8" > >I?m experimenting with setting up a Gemini server (molly brown in this >case) on my LAN. It is on a different network segment than my desktop >(client, trying out Kristall and elpher). When I try to connect to the >server, I get a message ?you tried to request a resource from one host >that is actually located on another host.... No proxying to other hosts >or ports.? The message is similar from the various clients and in the >server?s log file. > >Not sure why I?m getting this. Running on port 1965, no port forwarding >arrangement. There is a firewall between the two network segments. > >Thanks!
On Sun Jul 5, 2020 at 7:58 PM CEST, wrote: > Did I miss the mention in this group? > https://news.ycombinator.com/item?id=23730408 > > I saw lot of idle "concern" about viability and bike shedding, some > actual interest. > > Participated a little myself... Ah, this explains why there's been a small surge in requests for hosting at gemini.circumlunar.space! I won't bother looking at the HN thread, I know I'll just get bummed out by the stupid negative comments. But I'll brace myself for another small surge in interest. I wonder how many times this will happen? Cheers, Solderpunk
---
Previous Thread: Removing expiry dates for TOFU
Next Thread: [ANN] twinwiki, a Gemini wiki edited with sed commands