💾 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

View Raw

More Information

➡️ Next capture (2023-12-28)

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

Hacker News again

peteyboy@sdf.org <peteyboy (a) sdf.org>

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!

Link to individual message.

Solderpunk <solderpunk (a) posteo.net>

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

Link to individual message.

---

Previous Thread: Removing expiry dates for TOFU

Next Thread: [ANN] twinwiki, a Gemini wiki edited with sed commands